| 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". |
| |
| ▲ | everforward 2 days ago | parent | next [-] | | Let me preface this by saying it is wildly impractical, but you could boot into a separate, minimal OS that mounts your primary OS disk and manages those permissions. For an extra layer, have the “god mode OS” installed on physically read-only media, and mount the primary OS in a no-exec mode. Regular OS can’t modify permissions, and the thing that can modify permissions can’t be modified. It’s too clunky for home use, but could probably be used for things like VM images (where the “god mode OS” is the image builder, and changing permissions would require rebuilding the image and redeploying). | | |
| ▲ | theamk a day ago | parent [-] | | Some BSDs have concept of "securelevel" - a global setting that could be used to permanently put the system up into the mode which restricts certain operations, like writing to raw disks or truncating logs. The idea is if you want to modify the the system, you reboot into single-user mode and do what you need. It does not start up ssh / networking by default, so it is accessible to local console only. And of course plenty of smaller MCUs (used in IoT devices) can be locked down to prevent any sort of writing to program memory - you need an external programming adapter to update the code. This is the ultimate security in some sense - no matter what kinds of bugs you have, a power cycle will always restore system into pristine state (*unless there is a bug in settings parser). |
| |
| ▲ | charcircuit 3 days ago | parent | prev [-] | | >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. | | |
| ▲ | theamk 2 days ago | parent | next [-] | | > the build farm for the next OS update is a god object This is a very interesting question! It may sound meaningless to you, but modifying firmware images is pretty common when trying to modify locked-down hardware. As in, "I'll unpack the firmware image, set root password and enable telnet, then flash it back". So no, the build farm is not a god object. Whatever controls firmware updates is. Can any app initiate it? Or does it need user's password? Or maybe physical presence? Or a private key that only select people have? > If sudo couldn't be used from other programs / she'll scripts and doesn't give access to a god account.. But why require people to manually wrap programs.. So, you mean like what "polkit"? This is what systemd is doing - instead of requiring "sudo", commands like "systemctl start SOMETHING" will handle privilege escalation themselves. For example on my computer, running this in terminal pops-up interactive dialog asking for my password. In theory, you can have the whole suite of programs - "secure-cp", "secure-mv", "secure-edit" (see also: "sudoedit"), "secure-find", etc... But it seems pretty wasteful, no? Sure, most common actions (installing/removing apps, configuring networks) can get its own nice privilege-escalating wrappers, but there are many advanced tasks that user can do, and it's much easier to make (and audit) a single "sudo" than hundreds of random scripts. (Unless you want to have a fully locked-down system where the only OS creator can decide which privileged actions are allowed. Those things exists and are pretty popular: Android and iOS. They are also only usable for a very specific purposes, basically as a remote terminals to server machines running unrestricted OSes without such limitations) | |
| ▲ | soraminazuki 3 days ago | parent | prev [-] | | > 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. | | |
| ▲ | charcircuit 3 days ago | parent [-] | | 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. | | |
| ▲ | _flux 3 days ago | parent [-] | | 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. | | |
| ▲ | charcircuit 2 days ago | parent [-] | | You don't need to backup every file. It's a reasonable compromise to require users to login to their bank again when switching to a new computer. |
|
|
|
|
|
