summaryrefslogtreecommitdiffstats
path: root/sandbox/sandbox.gyp
diff options
context:
space:
mode:
authormarkus@chromium.org <markus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-04-20 18:05:23 +0000
committermarkus@chromium.org <markus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-04-20 18:05:23 +0000
commit00248036bdbbcd913adb34193cf21982a2fdc82a (patch)
tree15007b2ef02f6291e2a3f312c928ab2f6f0229bf /sandbox/sandbox.gyp
parentae654689c8fae6eb523054f073ce8baabf4ec2c5 (diff)
downloadchromium_src-00248036bdbbcd913adb34193cf21982a2fdc82a.zip
chromium_src-00248036bdbbcd913adb34193cf21982a2fdc82a.tar.gz
chromium_src-00248036bdbbcd913adb34193cf21982a2fdc82a.tar.bz2
Make the use of signals inside of the sandbox safe.
We previously assumed that no signals would ever be enabled in the sandbox and thus there was no way to trick the trusted thread into executing potentially untrusted code. In an attempt to lift this restriction, this changelist modifies the trusted thread so that - it has an invalid stack pointer at all times. Any attempt to handle a signal would result in the kernel trying to push a signal stack, which would immediately result in a SEGV and then terminate the application. - all signals are blocked while outside of trusted code. If a signal is triggered, it either gets handled on one of the sandboxed threads (for asynchronous signals), or it results in the application getting terminated by the kernel (for synchronous signals). This changelist is difficult not only because eliminating all uses of the stack pointer requires some very careful assembly coding, but more importantly because we have to restore signals after we enter seccomp mode. As sigprocmask() is a restricted system call, the only way to restore the signal mask is by calling sigreturn() with a suitably tweaked signal stack frame. While the first couple of bytes of the signal stack frame are well-defined and unlikely to change, the entire signal stack frame is not documented as part of the stable ABI. The exact format depends on the number of modified CPU registers (e.g. SSE, MMX, floating point, ...) The only way for us to get a valid signal stack frame is to trigger a signal, and to create a (possibly adjusted) copy of the signal frame. We obviously have to do this _before_ we block all signals upon entering trusted code. The two places where this needs to happen is upon start of the sandbox when launching the initial trusted thread, and upon any call to clone(). BUG=37728 TEST=Run chrome and verify that /proc/$PID/status shows the correct signal mask for trusted threads. The latter can be identified with strace. Review URL: http://codereview.chromium.org/1594040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45055 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'sandbox/sandbox.gyp')
-rw-r--r--sandbox/sandbox.gyp1
1 files changed, 1 insertions, 0 deletions
diff --git a/sandbox/sandbox.gyp b/sandbox/sandbox.gyp
index a835089..b73c1e5 100644
--- a/sandbox/sandbox.gyp
+++ b/sandbox/sandbox.gyp
@@ -181,6 +181,7 @@
'linux/seccomp/sandbox_impl.h',
'linux/seccomp/securemem.cc',
'linux/seccomp/securemem.h',
+ 'linux/seccomp/sigprocmask.cc',
'linux/seccomp/socketcall.cc',
'linux/seccomp/stat.cc',
'linux/seccomp/syscall.cc',