21 ms·

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

> 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.
- Blikkentrekker 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: 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.
  - saagarjha 6y ago
theamk 6y ago
Sorry, a quick response on one point: > 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.

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.

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

theamk 6y ago

Sorry, a quick response on one point: > 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.