Google's Chromium sandbox

Posted Aug 19, 2009 23:36 UTC (Wed) by ncm (guest, #165)
Parent article: Google's Chromium sandbox

Couldn't another process use ptrace to perform memory allocations and similar system calls on behalf of the restricted one, as gdb does? The restricted thread can actually be stopped during the call, making it unable to do anything to interfere. The secure thread would just be a two-instruction halt loop, then.

to post comments

Google's Chromium sandbox

Posted Aug 20, 2009 1:33 UTC (Thu) by njs (subscriber, #40338) [Link] (2 responses)

Clever approach, though it does have the minor flaw that you become unable to ever use a debugger on the main web browser guts (since only one process can ptrace() at a time).

Google's Chromium sandbox

Posted Aug 20, 2009 2:40 UTC (Thu) by ncm (guest, #165) [Link]

Nah, the parent and gdb hand off. Whenever the child process sends a request for a system call, that trips a breakpoint, and gdb lets go of the child, which stalls waiting on the parent. Gdb attaches to the parent, and the parent attaches to the child and does its business. When the system call is done, the parent releases its ptrace and hits a breakpoint of its own, and then gdb parks the parent on a read call, detaches from the parent and re-attaches to the child, has it send a wakeup to the parent, and then we're back where we started.

Google's Chromium sandbox

Posted Oct 15, 2009 21:57 UTC (Thu) by SEJeff (guest, #51588) [Link]

Whenever Roland finishes polishing it up, utrace will be merged in the
kernel. utrace removes the one ptrace / process limitation.