6 ms·
It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it c
It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it could give itself access to everything.
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.
> giving an application access to the input system gives an application access to everything
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.
> 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.
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.
> That's not what is commonly understood as access to the input system.
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.
> It would also mean that no modern browser works any more since they need access to far more to even start up.
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.
[0] https://firejail.wordpress.com/features-3/#namespaces https://firejail.wordpress.com/features-3/#namespaces
And still. If I can upload some text document or private picture with a web-browser onto some web host, then that web browser can also send that picture anywhere else to spy on me. Unless I need to give it permission every time I wish to do something such as that, which would be very cumbersome.
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.
There was am academic system (whose name I unfortunately cannot recall now) which would hook up the "file open" dialog and run it from trusted mode. When a user would pick up a file, then the program would have access to it, and only it. This apparently worked pretty great for programs which needed only one file. It probably would not have worked as great for programs which do more advanced stuff, like IDEs which need to be able to "search in files". I think modern Androids can do the same sometimes?
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.
> And still. If I can upload some text document or private picture with a web-browser onto some web host, then that web browser can also send that picture anywhere else to spy on me. Unless I need to give it permission every time I wish to do something such as that, which would be very cumbersome.
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.
> There's a reason that only a small minority of software can even run in such sandboxes
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.