I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a problem for me, but it would give me some comfort.
I really like it, though. New applications have to ask whether they can read/write from ~/Documents or ~/Pictures, or read contacts. I agree with you, and also wish something like this existed for modern Linux desktops.
The permissions are not interactive, you can set them once and forget.
I already use strace to understand what programs do but it would be great if I could also intercept these calls in real time. Just keep the program waiting until I approve its open system call on that specific file.
That's basically how strace is implemented anyways.
The same of course applies to giving it access to the file system.
Something so simple as an audio manipulation application must have access to the filesystem, unless one only will it to be able to save within a specific subsection thereof, and if it be granted such access, it can now edit whatever file stores whatever application has whatever permissions, thus giving itself full permissions.
The further problems with this scheme are that it's not entirely clear where the limits of one “application” lies which would have to be defined.
It makes a great deal of assumptions that may not be true.
This is also a problem with Linux capabilities. — I remember well an explanation where the auctor demonstrated how in about 2/3 of all Linux capabilities, they, or in combination with one other capability were sufficient to escalate to full root access on almost any modern normal system.
Many of these security restrictions are theoretical of nature, and on most systems amount to very little against a sufficiently skilled attacker, but do inspire a false sense of security.
> but it would give me some comfort.
And that is what it seems to truly be for: not making the user safe, but making him feel safe, and the latter often has a negative influence on the former.
How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging.
There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore.
> The same of course applies to giving it access to the file system.
uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure.
The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
That's not what is commonly understood as access to the input system.
> There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore.
So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless.
> uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure.
It would also mean that no modern browser works any more since they need access to far more to even start up.
You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system.
I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me.
Finally, even if this browser only have access to `~/Downloads`, it would still be capable of modifying any file that something else put there, thus allowing it to easily install malware into anything that anything els downloads, without the user's knowledge.
> The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
There is a good reason that SELinux never truly penetrated: — it is capable of much of this, but it would also make most applications unworkable and users would complain about no longer being able to do as they will.
More or less what the situation is on Android, or Windows.
Then most apps have no need to have access to the input system.
> So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless.
Sandboxing does not mean the OS cannot extend the sandbox on demand in response to user consent.
> You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system.
These should be enumerable.
> I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me.
See above for sandbox extensions.
I never said as much; I simply said that giving them access to it is tantamount to giving them full access, and that many other such privileges also are.
Eventually, the list is so large that many applications need access to at least one thing from which they may escalate to full access.
> Sandboxing does not mean the OS cannot extend the sandbox on demand in response to user consent.
The point is that as soon as one have given the text editor consent to write to arbitrary text files on the system, one has given it full access as now it can edit the file that contains these permissions.
In the alternative, one has to grant it access to files, or directories, on an individual basis with every save, which is something users will quickly grow tired off, especially if it be configured to periodically save.
> These should be enumerable.
They are, and users will quickly complain that it becomes unworkable to grant access to each of these individually.
> See above for sandbox extensions.
I would also become annoyed very quickly if I had to give permissions again every time I wanted to save elsewhere.
And you didn't address the fact that if he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
What you want can work in theory, but few users would be willing to live with their the extreme reduction in quality of life and productivity, or walled garden that results from it.
> Eventually, the list is so large that many applications need access to at least one thing from which they may escalate to full access.
This makes zero sense. If an app wants access to keylogging APIs, then it better be an app where it makes sense to be able to keylog other apps. 99% of apps have no reason to do this and have no need for full access.
> In the alternative, one has to grant it access to files, or directories, on an individual basis with every save,
No, the alternative is that you give the application access to a file and now it owns that file.
> And you didn't address the fact that if he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
You can deny the browser the ability to read or write to the directory in general, but it may create new files and have permission to those.
Overall, it is eminently possible to make useful software, perhaps even most useful software, that operates under a reasonable sandbox.
There's a reason that only a small minority of software can even run in such sandboxes without failing to work as intended or indeed pestering the user with dialogs for permission every second, and of many that can run in them, it's a security theatre that doesn't help if the software truly were malicious.
Are you running your text editor, terminal, IRC bouncer, or audio server in such a sandbox?
> This makes zero sense. If an app wants access to keylogging APIs, then it better be an app where it makes sense to be able to keylog other apps. 99% of apps have no reason to do this and have no need for full access.
There are, as said, far more things they need access to that can escalate to full privileges quickly:
- access to write arbitrary files owned by the user
- access to read from arbitrary ports that the user owns
- access to ptrace arbitrary processes the user runs
- access to edit the `PATH` of the user
> No, the alternative is that you give the application access to a file and now it owns that file.
Do you frequently use your text editor to edit one file, and one file only?
Give it access once to edit a script you wrote, now it owns the file; say it be malicious, it now changes the script so that next time it is executed, it allows for arbitrary code to run.
Not to mention having used it once to edit the initialization or environment variable files and user profiles.
> You can deny the browser the ability to read or write to the directory in general, but it may create new files and have permission to those.
In which case, it can exploit a race condition to replace a file that was created by something else immediately after the other software unlinks it to recreate it under the same name to trick the user.
It can also then create a symbolic link to trick other applications and gain write permissions of files it shouldn't have since almost no software is secured against such symbolic link attacks.
> Overall, it is eminently possible to make useful software, perhaps even most useful software, that operates under a reasonable sandbox.
It is, so long one be willing to forgo having basic control of one's system.
Android does it, as said, but in Android, the user does not enjoy such control, by design.
Again, it seems like you have not used macOS.
> Are you running your text editor, terminal, IRC bouncer, or audio server in such a sandbox?
What I am doing is not particularly relevant, given that I have needs that require me to run with SIP disabled (which, due to rather unfortunate design choices, means there are relatively trivial ways to escalate to root). However, there are many popular text editors that are sandboxed, for example the built-in TextEdit or CotEditor (which ships on the Mac App Store, to boot!). Terminals usually do not run in sandboxes for obvious reasons (although, many people are happy with the ones that run on iOS, so…). I don't run an IRC bouncer or audio server but I would certainly like it to run in sandbox, and can see a very clear way to have them do so.
> far more things they need access to that can escalate to full privileges quickly
The number of applications that need to do the things you mentioned are few are far between. I mean, honestly, does anything need to ptrace an arbitrary process other than a debugger? I think there is exactly one process on my computer that can edit PATH for my user…
> Do you frequently use your text editor to edit one file, and one file only?
Uh, is this not how you use a text editor?
> Give it access once to edit a script you wrote, now it owns the file; say it be malicious, it now changes the script so that next time it is executed, it allows for arbitrary code to run.
> Not to mention having used it once to edit the initialization or environment variable files and user profiles.
Yes, but again: user consent. If I give an app the ability to access a file, then it can access the file. If I don't, then it can't touch it. This is clearly better than "the app can do everything".
> In which case, it can exploit a race condition to replace a file that was created by something else immediately after the other software unlinks it to recreate it under the same name to trick the user.
> It can also then create a symbolic link to trick other applications and gain write permissions of files it shouldn't have since almost no software is secured against such symbolic link attacks.
Who said anything about this identity being tied to the filename, or even enforced by the application itself? Validation is done correctly in the kernel, of course.
Still, few programs need to change PATH, open arbitrary ports or ptrace other processes. These scenarios are so special that they should require explicit user approval. Also, apart from text editors, most programs don't ever need to access arbitrary files from the file system.
Android being locked down is a distributor's decision. They have average users in mind that might not ever need nor want to fiddle around on their system with a debugger and a text editor.
> if [t]he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
The solution is to give each program which uses Downloads folder its own folder. On my system, I think there are about 2 programs which can write to that folder, so this is not that much.
If it really bothers you that you have ~/Downloads/Firefox and ~/Downloads/Chromium, then there are things like mhddfs which "merge" two directories -- browsers actually save to `~/.downloads/Firefox` and `~/.downloads/Chromium` and you have a single unified "~/Downloads" folder which shows files from both.
You are thinking again about old-style permissions control -- like SELinux. Yes, they are not going to work well, as you cannot really deny .cache access.
But this is not what we do in the modern system. You start a new mount namespace, and then mount a new tmpfs over /home. Then you bind-mount outside ~/.config/protected-firefox-profile to a ~/.mozilla inside the sandbox. And you expose ~/Downloads as-is.
And then you run firefox in that sandbox -- none of the system calls fail, any file which was written can be read back (sometimes only until the browser restarts), but your ~/.bashrc is totally safe.
You can improve this as much as you want. For example, want a private /tmp except shared /tmp/.X11-unix ? Sure. Want to hide your /etc and /var except few selected files? no problem.
This still assumes that there is a "sandboxed" and "non-sanboxed" parts of the account. You'll restrict more dangerous programs, like browsers, network clients, and games -- and leave things like text editors unrestricted, so there is no problems with editing text files.
Oh, and the thing that I am described are not some theoretical TODOs -- they are all supported and usable. I am running my own system made out of shell scripts and duct tape, but there are products out there like firejail [0] which implement all that.
But yes, it's true that issues with the cache can be resolved with this, but not saving outside of a single file path, and whatever utility that then moves the file outside of that single path would still need full permissions or be granted permissions.
It can be done, but at the cost of a great deal of convenience and restrictions.
But practically, as a person who runs sandboxed browser daily, it there is not "a great deal of convenience and restrictions". Even before sandbox, I'd download files to default location and later move some of them elsewhere -- so this is not really changing. A requirement to place files which need to be uploaded into a shared folder is somewhat annoying, but I found out that I don't upload that many files from browsers anyway.
Now you are moving goalposts. Initially, you were discussing restrictions on the file system.
I concur that the current desktop security model is probably unfixable. All the tools to improve on it are here though. Android kinda solved it by restricting every app to its own assets and files by default. If the app needs more, it has to ask for permissions.
The problem with user approval for every single action is decision fatigue. It is already happening on Android: every app is asking for a ton of permissions. And it turns out that many of them are not granular enough. For example, Signal needs the numbers from the address book to find contacts, but nothing else. If I want that feature, I still have to give Signal access to the entire address book.