sandboxes, sandboxes everywhere

lysa myers drew my attention to some interesting developments in the sandboxing arena last week. at first i thought she might be referring to security companies adding sandboxing to their arsenal (which i'd really like to see more security vendors do), but that's not it at all. it's actually sandboxing being added to individual applications. not only will adobe reader now come with it's own sandbox, but dell is coming up with a sandboxed version of firefox too.

i have mixed feelings about this sort of development. on the one hand it's nice to see sandboxing getting more attention and use, and these efforts will surely bring the technique to the masses. but on the other hand i worry about the effects of baking sandboxing into applications - especially applications that might call each other.

if something is running inside a sandbox and it executes an external program, that program should also run inside the same sandbox (otherwise the sandbox is rather simple to escape from). what happens, then, when the dell kace secure browser (which runs in it's own sandbox) launches adobe reader (as it would generally be expected to do when you click on a pdf link)? would we have adobe's sandbox nested within the browser's sandbox? how would that work - specifically how well (or poorly) would it work? you may recall that google's chrome had it's own sandboxing right from day 1 but that there were problems coexisting with other sandboxing technology (that i discussed here). the conflict between chrome and sandboxie seems to have been resolved but, as more and more applications come with sandboxing baked in, further inter-sandbox incompatibilities seem like a pretty likely outcome.

not only is cross compatibility between sandboxes a problem, but the question of implementation efficacy is an issue too. chrome's baked in sandbox was easy to escape because chrome's sandbox wasn't complete. it was only able to sandbox a narrowly defined set of processes specific to the browser itself - it couldn't even sandbox the plugins that it ran in order to render rich content like flash. it stands to reason that any baked in sandboxing technology is only going to be good enough to sandbox the application it's baked into. if the sandboxing technology was good enough to handle all the secondary processes that an application might launch then the technology might as well be made into a general purpose sandboxing product instead of being baked into an application. some may be better than others and people may be lulled into a false sense of security by thinking that the sandbox baked into application X is as good at protecting them as the sandbox baked into application Y.

i'm a big proponent of sandboxing, but i don't think sandbox sprawl is a good thing. it would eventually replace a few discrete sandboxes with known properties and known shortcomings with a ridiculous number of sandboxes with unknowable properties and shortcomings and cross compatibility issues. i'd prefer to see users using one or two general purpose sandboxes than dozens of  custom sandboxes.