Linked by Thom Holwerda on Wed 3rd Jun 2009 11:21 UTC, submitted by Hakime
One of the defining features of Google's Chrome web browse is its sandboxing feature. You probably won't realise it's there, but from a security point of view, sand-boxing is one of the most impotant factors in browser security, as it severely limits the amount of damage a security hole can do: sure, you've got a hole in the browser, but thanks to sandboxing, you're pretty much locked in - until you break out of the sandbox, of course. Sandboxing on the Windows variant of Chrome was a "complicated affair", says Chromium developer Jeremy Moskovich, but for the Mac version, it's all a bit easier and more straightforward. On Linux, however, it's a mess.
Permalink for comment 366885
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2005-06-29
I'm not familiar with seccmp, but if it's universal and stable, it seems -- perhaps with a small extension -- to be an elegant solution to this problem.
The extension (if it cannot be done currently) would be to allow the signal sent to be catchable. Then all that should be needed is a signal handler that would take the prohibited system calls and map them to an RPC call to a server process which would filter the requests and service those which are acceptable. The server process could be multithreaded child process of the browser, and would have general permission.
This seems to me a cleaner and more elegant way to handle this than to try to build a "one size fits all" sandbox mechanism.