> 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.
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.
> 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.
Text editors and all programs that can create executable files are huge special cases. Everything touched by them should be marked as "tainted" and should require explicit user blessing to leave their sandbox. Windows does something similar already with downloaded files.
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.
> 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.
> 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.
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.