Comment by btrask
10 years ago
I think it's worth distinguishing two problems with pledge:
1. It's likely to have bugs because it's mixed with a constantly changing kernel and can't be proven correct
2. It isn't fine-grained enough
If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations.
> If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations.
I think the idea that you can allow a program to get itself in an attacker-controlled state and that will be ok as long as you blacklist what the program can do is fundamentally unworkable. So yes, I think pledge-like approaches are always going to be worthless in the long term - if the program is under the attacker's control, it will almost certainly have enough access to be able to do damage (with a sufficiently skilled attacker), because every program does something, particularly if we're talking about a large and complicated program like a browser. (You could potentially segregate the browser into multiple processes with distinct responsibilities, but I'm not convinced that helps, because those processes still have to send commands to each other and so an attacker who can subvert one can probably control the others).
If it had the level of granularity to express restrictions like "should be able to write only files that the local user has chosen via the save dialogue" then it might become an effective security layer, but at that point we're not really talking about a sandbox any more.
You are correct that pledge itself (or seccomp+namespaces on Linux) does not form a useful sandbox. These mechanisms are useful for blocking out the world, but not for re-establishing access to certain resources that the app needs to do its job.
> "should be able to write only files that the local user has chosen via the save dialogue"
The web platform, incidentally, supports this! You can invoke a "choose file" dialog, and then your web page gets access to the one file the user chose.
In capability-based security circles, this pattern is called a "Powerbox". The pattern works especially well in capability systems, where it can be used to choose more than just files.
https://sandstorm.io/how-it-works#capabilities
I think your concern about "what if the sandbox can do too much" is reasonable. My only suggestion is to try out Qubes for a while. It requires some adaption, but it's definitely possible to use securely (edit: obviously limited by the realities of Xen).
FWIW, Apple's Mac sandbox and Sandstorm both have open/save support. It's definitely user-friendly and nice polish, but I don't think it's a make-or-break issue.