I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing.
[1] - https://developer.apple.com/library/mac/documentation/Darwin...
I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing.
[1] - https://developer.apple.com/library/mac/documentation/Darwin...
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.
Maybe, but the attacker can also get their certificate revoked when their activities are discovered.
It cannot simultaneously be easy for anyone to get a certificate and hard for an attacker to get a certificate.
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.
Yes, he could. No, it's not silly.
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.