If so, what are these OSes? Are they specially crafted? How difficult is it to apply this kind of program verification to the everyday OSes we use?
If not, why haven't people invented such OSes?
Package signature verification is quite common with today's package managers. What I'm asking about is signature verification at loading time.
iOS and Android both validates the signature of every single piece of code before loading them into memory.
Windows UWP apps are also all checked for signature before being loaded as well.
Package signature verification is quite common with today's package managers. What I'm asking about is signature verification at loading time.
The difference is massive in terms of performances. A package signature is checked when it is installed and not afterward.
To be effective, code signing must be checked for every binary before it is executed or loaded.
Furthermore, special care must be taken by the OS (or runtime environment) in order to make sure a memory page marked as executable is signed (or, at least, that is has been loaded from something that was properly signed). That requirements is extremely hard to enforce on any environment that wasn't designed with code signing in mind because it tends to break a lot of legacy code.
Why do not all OS verify signature of programs? Simply because in the early times, most programs were written and compiled locally, and still nowadays, some business applications are specifically built locally. A lot of high quality programs are distributed as source and can be compiled locally. It often make sense on high performance servers because compilation options can be used to tweak a program for specific needs. If you could only use signed executable from well-known sources, all that would not be possible.
Of course for an OS targeted to end users like Android or iOS things go different, and it makes sense to only allow executable installed from well known sources.
But even on my Windows box, I would be very disappointed if I could not write, build and execute a program in C or C++...
One example that's occasionally used in education and corporate environments is AppLocker, which can restrict application execution to a whitelist based on administrator-defined attributes, including the publisher name from a signature, or the hash of a specific file.
The biggest problem is of course the administration overhead, having to specifically whitelist all programs a user could possibly need. Additionally, many publishers don't sign their applications. And of course it's not a foolproof solution - e.g. a bug in a whitelisted program could still be exploited to run arbitrary code1.
Actually, the executable's signature isn't even the important part. The whitelist can be implemented by path for all the difference it makes - what's important in this scheme is that the user has no write permissions to the program directory2. Assuming that's true, what advantage does verification at execution time provide over verification at install time? No one can change the installed program. If the attack vector is offline editing of files, full disk encryption is the correct answer.
1 Most such bugs would not be considered severe in a normal environment, where they would not lead to privilege escalation. W^X can still be bypassed with ROP.
2 Even verification of signature of the executable will miss external modules (e.g. dynamically-linked libraries) by default. And enabling that can have significant performance impacts.
Linux already has the necessary mechanisms in the kernel (since version 3.7), called IMA:
The goals of the kernel integrity subsystem are to detect if files have been accidentally or maliciously altered, both remotely and locally, appraise a file's measurement against a "good" value stored as an extended attribute, and enforce local file integrity. These goals are complementary to Mandatory Access Control (MAC) protections provided by LSM modules, such as SElinux and Smack, which, depending on policy, can attempt to protect file integrity.
With IMA, sensitive files can be labelled "immutable" (which is what you'd do with executable files), which signs them with a special RSA key. The signature is validated on file access, preventing offline tampering. Executing files which are not immutable can be prohibited via SElinux policies.
Of course, usability of such a system is reduced. To build and execute your own files on such a system, you will need a trusted private key to sign them first. Software upgrades are likely to require a reboot in order to update immutable files before they are locked.
Load time verification is very expensive and not fool proof.
Are there any OSes that verify program signatures before executing them?
EDIT: As pointed out in comments, such operating systems. ChromeOS for e.g.
If so, what are these OSes? Are they specially crafted? How difficult is it to apply this kind of program verification to the everyday OSes we use?
It is fairly difficult to verify a program at loading time. Plus even if you successfully do it, once a program has been started the attacker can still give malformed input and cause havoc(buffer overflows). Having said that, there are software modules that verify their signatures at load time (Software attestation e.g.FIPS compliant OpenSSL). Having an operating system do it for each and every process is very very expensive.
As the focus shifts towards cloud computing, you would want to ensure that you are able to run high assurance software on even untrusted systems. I would say that not a lot of research would be done on protecting the system from the software that is running on it. Instead the focus will be more on doing trusted computation even in untrusted environment. You can have a basic chain of trust like system or software attestation (refer the bottom link) if you want at load time. The important thing would be ensuring that the software isn't compromised at run-time.
Look at this discussion: Can a running interpreted program cryptographically prove it is the same as as a published source code version?
Many answers mention general OSes having relatively recent support, but I see no mention of TPMs and the Trusted Computing Group. A TPM provides the minimum necessary hardware to do signed execution with a chain of integrity up from firmware boot as a standardized consumer grade motherboard module. It works by allowing boot stages to extend hash registers with measurements of each subsequent stage before execution, and then providing a locked keystore mechanism that can be conditional on these hash register values.
With the TPM solving the Chicken and Egg problem for PKI and early boot, resource access could be restricted to software allowed in a specific policy to whatever extent that code was itself exploit free. Without a verified boot, there is little point in runtime signature checking with no reason to believe the PKI system and policy is unmodified.
To my knowledge (which is not current), only Apple and Google had enough control of their hardware platforms to experiment with on-by-default TPMs and I don't think either implemented a complete TCG style of verified boot. But the threat of being left behind by a sudden uptake of these new devices caused OS vendors to start implementing some runtime integrity components.
NetBSD has veriexec.
https://wiki.netbsd.org/guide/veriexec/
https://www.netbsd.org/docs/guide/en/chap-veriexec.html
It is very well suited for Internet-facing servers, along with a raised securelevel ( https://wiki.netbsd.org/kernel_secure_levels/#index2h1 ).
Firstly, I am clearly a non-expert on anything I am about to say so be cautious...
In the free software world I live in, people are working on reproducible builds. The goal is that every binary downloaded could be verified by the user themselves by, well, building it. Many distros and software projects are interested in it. If I remember correctly, this idea was started by the bitcoin people and followed by the tor project.
From what I have heard, some people suggested after sufficiently many packages are reproducible, the hash could be shared in some p2p ways. So to answer your question, in my opinions, at loading time, a verifier can simply hash the binary and check if it matches the hash published by the others, although this may be slow depending on your internet connection speed (maybe the connection has to go through tor).
Also, I happen to know 2 distros more than others so I will elaborate more with them:
From what I have heard, Debian will make reproducible-build a policy requirement after sufficiently many packages are reproducible.
Guix implements guix challenge command so that one can verify the hash of your local build with the official build on Hydra.
I am not an 'expert' but just a common user of some of the tools.
Am sharing about reproducible builds a bit more and as comments was not the right place, hence sharing here. From what little I understand, used and experimented, what it does it gives you a .deb package along with a .buildinfo text file. The buildinfo text file will have names and version numbers of all libraries which were needed in the build environment to make the binary.
So if you are suspicious about a binary package (from the archive or even outside) which has the buildinfo text file, it may or may not be triviai to test the packages by re-creating the exact build environment and comparing the hashes of the final binary packages.
It may also be possible to have some sort of web of trust so that more people can jump and say that the hashes match making it somewhat more reliable perhaps. There may be edge-cases that I don't know about.
Microsoft Windows 7+ can be configured to only allow Authenticode signed programs to run.
But you have to understand, that this only means you know who made the virus that destroyed your computer. It is not really a security feature, because it doesn't tell you anything about a application that it is signed. Yes, you know that $RANDOM_GUY from China, Ukraine, Angola, wherever created it. But what good would this really do you, if your valuable data is encrypted and $RANDOM_GUY demands 20BTC to decrypt it. And if the software steals all your data, then what good will it do you that you know $RANDOM_GUY probably stole it?
