diff options
author | markus@chromium.org <markus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-04-20 18:05:23 +0000 |
---|---|---|
committer | markus@chromium.org <markus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-04-20 18:05:23 +0000 |
commit | 00248036bdbbcd913adb34193cf21982a2fdc82a (patch) | |
tree | 15007b2ef02f6291e2a3f312c928ab2f6f0229bf /sandbox/sandbox.gyp | |
parent | ae654689c8fae6eb523054f073ce8baabf4ec2c5 (diff) | |
download | chromium_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.gyp | 1 |
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', |