short thought on sandboxing

jeremiah grossman recently penned a guest post for zdnet extolling the virtues of sandboxing. i've made no secret about the fact that i'm also a fan of sandboxing (though i'm not entirely on board with jeremiah's depiction of it with regards restricting things - that verges too close to behaviour blocking for liking) but the sandboxing jeremiah was referring too was the kind that is built into applications as a feature.

not too long ago posted about sandboxes being added to all sorts of apps and wondered (well, suggested) that such sandbox sprawl might not be the best way to go about things. jeremiah's observation that adding sandboxes to apps changes the game from a one exploit show to a two exploit show made me realize another reason why relying on the application's own sandbox is less than ideal - the attacker knows exactly which sandbox they have to escape from.

by contrast, with a separate stand alone sandbox, an attacker wouldn't necessarily know which sandbox is involved and would then need to develop escape exploits for multiple sandboxes and try the shotgun approach, firing them all at once and hoping for the best.

i do believe i'll be sticking with the stand alone sandbox. it seems to have the tactical advantage.

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.