4 ms·

> 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 pr

> 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.

saagarjha 6y ago
> 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.
- Blikkentrekker 6y ago
  > Then most apps have no need to have access to the input system. 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.
  - saagarjha 6y ago
    Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here: > 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.
theamk 6y ago
> 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
- Blikkentrekker 6y ago
  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.
  - theamk 6y ago
    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.

saagarjha 6y ago

> 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.

Blikkentrekker 6y ago
> Then most apps have no need to have access to the input system. 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.
- saagarjha 6y ago
  Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here: > 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.

theamk 6y ago

> 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

Blikkentrekker 6y ago
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.
- theamk 6y ago
  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.