Are there any OSes that verify program signatures before executing them?
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.