Code signing is not interesting. If normal people can get their code signed then so can the attacker and if they can't then it locks you out of your own computer. The only thing code signing is really good for is to verify that an update to a program the machine's owner installed was signed by the same author as the original program, and unfortunately it's rarely implemented that way.
But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing.
The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.
> That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code
That's like saying kernel memory protection is silly when the user is an admin because he could just as well load a driver into the system to wreak whatever havoc he wants.
Memory protection is not silly. Not being able to bypass memory protection (and therefore prohibiting all manner of debugging tools) is silly, and that is the appropriate analogy.
If a user correctly has permission to do a thing via a series of ugly hacks then there is no reason not to just let the user do the thing directly.
...if their activities are discovered. And then the attacker just gets another certificate under a different name, or steals somebody else's certificate. Ignoring, of course, that revocation is totally broken.
It cannot simultaneously be easy for anyone to get a certificate and hard for an attacker to get a certificate.
But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing.
The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.