The problem is how do you set up those permissions without a god object? How do you fix ones that are broken on a running system?
Ultimately the security systems that introduce high complexity in the name of fine grain permission controls end up being the most fragile and hardest to verify. People get stuff wrong then break it further trying to get their job done. The better system is sometimes the one that doesn’t have all of the features but is comprehensible to humans.
If an app requires a permission, how does OS know that it's OK to grant it? For example, I want to backup my system, so I install app which needs a permission called "bypass any file access control and let me read every file". How does OS know it's legitimate and not malware trying to steal data?
It could be "this requires special digital signature from OS manufacturer" -> then the private key of this digital signature is a "god object"
It could be "this requires confirmation from the physically present user" -> then you basically have passwordless sudo
It could be "this requires users pin/password/biometrics" -> then you have regular sudo
Either way, there is some source of authority in here, even if it's called "root key" or "user pin" instead of "root account".
>then the private key of this digital signature is a "god object"
You could instead require the app to be part of the OS. The next gotcha would from you I imagine is that the build farm for the next OS update is a god object and at that point I think this is a meaningless tangent. I'll concede and say you have to trust your OS creator. But you always have to trust your OS creator for any OS.
>then you basically have passwordless sudo
If sudo couldn't be used from other programs / she'll scripts and doesn't give access to a god account, but instead did simple things like let you use ping, then that seems fine to me. But why require people to manually wrap programs when it could be handled automatically.
>Either way, there is some source of authority in here
Sure, but it's a system that's much better than sudo.
> You could instead require the app to be part of the OS.
That almost sounds like you're advocating for the abolishment of third party or user-made apps that can make changes to the system without the approval of the manufacturer.
This is about being able to read any file on the system including things like the user's bank authentication tokens. No 3rd party developers should be able to read bank authentication tokens. The OS should create a safer API for 3rd parties to use for the use case they want.
Doesn't this just move the bucket: which processes should the OS grant access to that API?
In any case, if the purpose is to make a backup of the system, it seems the possibility to read all and every file as original as possible seems rather critical, in particular if we want to take advantage of e.g. content-based addressing -based deduplication in the backup application. And we in any case want to restore that backup to an empty computer, so there really are no places to hide the encryption keys in such a way that they cannot be read from the backup.
Have you ever tried to fix an application that was getting denied based on SELinux policies? It's a cryptic nightmare. You run a tool that gives you some magic string and hope that it works because nobody really understands what's going on. If that doesn't work you're in a world of pain. Almost as bad as Microsoft's ACLs.
Ultimately the security systems that introduce high complexity in the name of fine grain permission controls end up being the most fragile and hardest to verify. People get stuff wrong then break it further trying to get their job done. The better system is sometimes the one that doesn’t have all of the features but is comprehensible to humans.