Google's Chromium sandbox

Posted Aug 19, 2009 20:54 UTC (Wed) by kjp (guest, #39639)
Parent article: Google's Chromium sandbox

It looks like in essence, instead of trapping straight to the kernel, you are restricting the untrusted renderer to trap to a supervisor, that can then validate and trap to the kernel.

Was there consideration of using x86 ring 1 or 2 for this purpose? Is that too architecture dependent?

Anyway... still an interesting idea. The syscall table looks refreshingly small. I noticed things like socket, connect aren't in there... I take it the network IO is still running in the trusted/main process?

Google's Chromium sandbox

Posted Aug 19, 2009 22:03 UTC (Wed) by agl (guest, #4541) [Link]

I didn't consider it, but I believe that using CPU for protection (ring 1/2)
would require changes in the kernel. The beauty of seccomp is that it's been
in the kernel for several years now and is quite widely deployed.

Also, you're correct that all network IO runs in the main browser process.
This is actually a little unfortunate: it would be best to have a separate,
sandboxed process for that but, alas, that's only a wishlist item for now.

Google's Chromium sandbox

Posted Aug 19, 2009 22:22 UTC (Wed) by ikm (guest, #493) [Link]

Actually, seccomp looks like it was meant to be used exactly like this. That's why it was basically only given read and write, nothing more.