Sandboxing made easy

Posted Aug 20, 2009 0:14 UTC (Thu) by man_ls (guest, #15091)
Parent article: Google's Chromium sandbox

This is probably a stupid question, but I have to ask. Why not use read() and write() to make the untrusted part communicate with the trusted part, via a pipe? The untrusted part (a process) could decipher the HTML, and then send the result in an intermediate form to the trusted part (another process) for it to display that on the screen. Any compromise would have to generate an intermediate "poisoned" form that did something bad to the trusted part, but sending the malicious payload would be really difficult.

It does look quite complex, but the sandboxing is not trivial either.

to post comments

Sandboxing made easy

Posted Aug 20, 2009 0:33 UTC (Thu) by Simetrical (guest, #53439) [Link] (1 responses)

Apparently because you need to be able to do things like allocate memory on
the heap, and the restricted thread can't do that. So you need a trusted
thread running in the same process.

Sandboxing made easy

Posted Aug 20, 2009 18:13 UTC (Thu) by man_ls (guest, #15091) [Link]

Ah, but of course -- sounds obvious once it is pointed out. Stupid dangers of memory management!

Sandboxing made easy

Posted Aug 20, 2009 16:25 UTC (Thu) by martine (guest, #59979) [Link]

That is in fact already how Chrome works, and yes, it is rather complicated.
See
http://dev.chromium.org/developers/design-documents/multi...
architecture

This article about the architecture used to make the HTML-decoding process
both sandboxed but still powerful enough to convert HTML into images (which
are then sent back to the trusted process).