IMPORTANT NOTE: The Linux SUID sandbox is almost but not completely removed. See https://bugs.chromium.org/p/chromium/issues/detail?id=598454 This page is mostly out-of-date.
SUID helper binary is called
chrome_sandbox and you must build it separately from the main ‘chrome’ target. To use this sandbox, you have to specify its path in the
linux_sandbox_path GYP variable. When spawning the zygote process, if the
SUID sandbox is enabled, Chromium will check for the sandbox binary at the location specified by
linux_sandbox_path. For Google Chrome, this is set to
/opt/google/chrome/chrome-sandbox, and early version had this value hard coded in
In order for the sandbox to be used, the following conditions must be met:
SUIDand executable by other.
If these conditions are met then the sandbox binary is used to launch the zygote process. Once the zygote has started, it asks a helper process to chroot it to a temp directory.
The sandbox does three things to restrict the authority of a sandboxed process. The
SUID helper is responsible for the first two:
SUIDhelper chroots the process. This takes away access to the filesystem namespace.
SUIDhelper puts the process in a PID namespace using the
CLONE_NEWPIDoption to clone(). This stops the sandboxed process from being able to
ptrace()each other. More specifically, it stops the sandboxed process from being
ptrace()'d by any other process. This can be switched off with the
CLONE_NEWPID. If the
SUIDhelper is run on a kernel that does not support
CLONE_NEWPID, it will ignore the problem without a warning, but the protection offered by the sandbox will be substantially reduced. See LinuxPidNamespaceSupport for how to test whether your system supports PID namespaces.
This is an alternative to the
CLONE_NEWPID method; it is not currently implemented in the Chromium codebase.
Instead of using
SUID helper can use
setuid() to put the process into a currently-unused UID, which is allocated out of a range of UIDs. In order to ensure that the
UID has not been allocated for another sandbox, the
SUID helper uses getrlimit() to set
RLIMIT_NPROC temporarily to a soft limit of 1. (Note that the docs specify that setuid() returns
RLIMIT_NPROC is exceeded.) We can reset
RLIMIT_NPROC afterwards in order to allow the sandboxed process to fork child processes.
As before, the
SUID helper chroots the process.
As before, LinuxZygote can set itself to be undumpable to stop processes in the sandbox from being able to
ptrace() each other.
ptrace()a sandboxed process because they run under different UIDs. This makes debugging harder. There is no equivalent of the
--allow-sandbox-debuggingother than turning the sandbox off with
SUIDhelper can check that a
UIDis unused before it uses it (hence this is safe if the
SUIDhelper is installed into multiple chroots), but it cannot prevent other root processes from putting processes into this
UIDafter the sandbox has been started. This means we should make the
UIDrange configurable, or distributions should reserve a
SUID helper uses CLONE_NEWNET to restrict network access.
We are splitting the
SUID sandbox into a separate project which will support both the
setuid() methods: http://code.google.com/p/setuid-sandbox/
SUID helper as a separate project should make it easier for distributions to review and package.
Older versions of the sandbox helper process will only run
/opt/google/chrome/chrome. This string is hard coded (
sandbox/linux/suid/sandbox.cc). If your package is going to place the Chromium binary somewhere else you need to modify this string.