Chromium linux suid sandbox

Linux Sandboxing

Chromium uses a multiprocess model, which allows to give different privileges and restrictions to different parts of the browser. For instance, we want renderers to run with a limited set of privileges since they process untrusted input and are likely to be compromised. Renderers will use an IPC mechanism to request access to resource from a more privileged (browser process). You can find more about this general design here.

We use different sandboxing techniques on Linux and Chrome OS, in combination, to achieve a good level of sandboxing. You can see which sandboxes are currently engaged by looking at chrome://sandbox (renderer processes) and chrome://gpu (gpu process).

We have a two layers approach:

• Layer-1 (also called the “semantics” layer) prevents access to most resources from a process where it’s engaged. The setuid sandbox is used for this.
• Layer-2 (also called “attack surface reduction” layer) restricts access from a process to the attack surface of the kernel. Seccomp-BPF is used for this.

You can disable all sandboxing (for testing) with —no-sandbox .

Layered approach

One notable difficulty with seccomp-bpf is that filtering at the system call interface provides difficult to understand semantics. One crucial aspect is that if a process A runs under seccomp-bpf , we need to guarantee that it cannot affect the integrity of process B running under a different seccomp-bpf policy (which would be a sandbox escape). Besides the obvious system calls such as ptrace() or process_vm_writev() , there are multiple subtle issues, such as using open() on /proc entries.

Our layer-1 guarantees the integrity of processes running under different seccomp-bpf policies. In addition, it allows restricting access to the network, something that is difficult to perform at the layer-2.

Sandbox types summary

Name	Layer and process	Linux flavors where available	State
Setuid sandbox	Layer-1 in Zygote processes (renderers, PPAPI, NaCl, some utility processes)	Linux distributions and Chrome OS	Enabled by default (old kernels) and maintained
User namespaces sandbox	Modern alternative to the setuid sandbox. Layer-1 in Zygote processes (renderers, PPAPI, NaCl, some utility processes)	Linux distributions and Chrome OS (kernel >= 3.8)	Enabled by default (modern kernels) and actively developed
Seccomp-BPF	Layer-2 in some Zygote processes (renderers, PPAPI, NaCl), Layer-1 + Layer-2 in GPU process	Linux kernel >= 3.5, Chrome OS and Ubuntu	Enabled by default and actively developed
Seccomp-legacy	Layer-2 in renderers	All	Deprecated
SELinux	Layer-1 in Zygote processes (renderers, PPAPI)	SELinux distributions	Deprecated
AppArmor	Outer layer-1 in Zygote processes (renderers, PPAPI)	Not used	Deprecated

The setuid sandbox

Also called SUID sandbox, our main layer-1 sandbox.

A SUID binary that will create a new network and PID namespace, as well as chroot() the process to an empty directory on request.

To disable it, use —disable-setuid-sandbox . (Do not remove the binary or unset CHROME_DEVEL_SANDBOX , it is not supported).

User namespaces sandbox

The namespace sandbox aims to replace the setuid sandbox. It has the advantage of not requiring a setuid binary. It’s based on (unprivileged) user namespaces in the Linux kernel. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported.

Starting with M-43, if the kernel supports it, unprivileged namespaces are used instead of the setuid sandbox. Starting with M-44, certain processes run in their own PID namespace, which isolates them better.

The seccomp-bpf sandbox

Also called seccomp-filters sandbox.

Our main layer-2 sandbox, designed to shelter the kernel from malicious code executing in userland.

Also used as layer-1 in the GPU process. A BPF compiler will compile a process-specific program to filter system calls and send it to the kernel. The kernel will interpret this program for each system call and allow or disallow the call.

To help with sandboxing of existing code, the kernel can also synchronously raise a SIGSYS signal. This allows user-land to perform actions such as “log and return errno”, emulate the system call or broker-out the system call (perform a remote system call via IPC). Implementing this requires a low-level async-signal safe IPC facility.

seccomp-bpf is supported since Linux 3.5, but is also back-ported on Ubuntu 12.04 and is always available on Chrome OS. See this page for more information.

See this blog post announcing Chrome support. Or this one for a more technical overview.

This sandbox can be disabled with —disable-seccomp-filter-sandbox .

The seccomp sandbox

Also called seccomp-legacy . An obsolete layer-1 sandbox, then available as an optional layer-2 sandbox.

Deprecated by seccomp-bpf and removed from the Chromium code base. It still exists as a separate project here.

SELinux

Deprecated. Was designed to be used instead of the SUID sandbox.

Old information for archival purposes:

One can build Chromium with selinux=1 and the Zygote (which starts the renderers and PPAPI processes) will do a dynamic transition. audit2allow will quickly build a usable module.

Available since r26257, more information in this blog post (grep for ‘dynamic’ since dynamic transitions are a little obscure in SELinux)

Developing and debugging with sandboxing

Sandboxing can make developing harder, see:

Источник

Chromium linux suid sandbox

Copy raw contents

Linux SUID Sandbox Development

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.

We need a SUID helper binary to turn on the sandbox on Linux.

In most cases, you can run build/update-linux-sandbox.sh and it’ll install the proper sandbox for you in /usr/local/sbin and tell you to update your .bashrc if needed.

Installation instructions for developers

If you have no setuid sandbox at all, you will see a message such as:

If your setuid binary is out of date, you will get messages such as:

Run the script mentioned above, or do something such as:

Build chrome_sandbox whenever you build chrome ( ninja -C xxx chrome chrome_sandbox instead of ninja -C xxx chrome )

After building, run something similar to (or use the provided update-linux-sandbox.sh ):

Put this line in your

/.bashrc (or .zshenv etc):

Try bots and waterfall

If you’re installing a new bot, always install the setuid sandbox (the instructions are different than for developers, contact the Chrome troopers). If something does need to run without the setuid sandbox, use the —disable-setuid-sandbox command line flag.

The SUID sandbox must be enabled on the try bots and the waterfall. If you don’t use it locally, things might appear to work for you, but break on the bots.

(Note: as a temporary, stop gap measure, setting CHROME_DEVEL_SANDBOX to an empty string is equivalent to —disable-setuid-sandbox )

Disabling the sandbox

If you are certain that you don’t want the setuid sandbox, use —disable-setuid-sandbox . There should be very few cases like this. So if you’re not absolutely sure, run with the setuid sandbox.

If you’re using a «raw» build of Chromium, do the following:

You can also make such an installation more permanent by following the steps above and installing chrome_sandbox to a more permanent location.

System-wide installations of Chromium

The CHROME_DEVEL_SANDBOX variable is intended for developers and won’t work for a system-wide installation of Chromium. Package maintainers should make sure the setuid binary is installed.

Источник

Linux SUID Sandbox Development

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.

We need a SUID helper binary to turn on the sandbox on Linux.

In most cases, you can run build/update-linux-sandbox.sh and it’ll install the proper sandbox for you in /usr/local/sbin and tell you to update your .bashrc if needed.

Installation instructions for developers

If you have no setuid sandbox at all, you will see a message such as:

If your setuid binary is out of date, you will get messages such as:

Run the script mentioned above, or do something such as:

Build chrome_sandbox whenever you build chrome ( ninja -C xxx chrome chrome_sandbox instead of ninja -C xxx chrome )

After building, run something similar to (or use the provided update-linux-sandbox.sh ):

Put this line in your

/.bashrc (or .zshenv etc):

Try bots and waterfall

If you’re installing a new bot, always install the setuid sandbox (the instructions are different than for developers, contact the Chrome troopers). If something does need to run without the setuid sandbox, use the —disable-setuid-sandbox command line flag.

The SUID sandbox must be enabled on the try bots and the waterfall. If you don’t use it locally, things might appear to work for you, but break on the bots.

(Note: as a temporary, stop gap measure, setting CHROME_DEVEL_SANDBOX to an empty string is equivalent to —disable-setuid-sandbox )

Disabling the sandbox

If you are certain that you don‘t want the setuid sandbox, use —disable-setuid-sandbox . There should be very few cases like this. So if you’re not absolutely sure, run with the setuid sandbox.

Installation instructions for “Raw builds of Chromium”

If you’re using a “raw” build of Chromium, do the following:

You can also make such an installation more permanent by following the steps above and installing chrome_sandbox to a more permanent location.

System-wide installations of Chromium

The CHROME_DEVEL_SANDBOX variable is intended for developers and won’t work for a system-wide installation of Chromium. Package maintainers should make sure the setuid binary is installed.

Источник

Chromium linux suid sandbox

Linux SUID Sandbox

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.

With r20110, Chromium on Linux can now sandbox its renderers using a SUID helper binary. This is one of our layer-1 sandboxing solutions.

SUID helper executable

The 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 chrome/browser/zygote_host_linux.cc .

In order for the sandbox to be used, the following conditions must be met:

• The sandbox binary must be executable by the Chromium process.
• It must be SUID and 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:

• The SUID helper chroots the process. This takes away access to the filesystem namespace.
• The SUID helper puts the process in a PID namespace using the CLONE_NEWPID option to clone(). This stops the sandboxed process from being able to ptrace() or kill() unsandboxed processes.

• The Linux Zygote startup code sets the process to be undumpable using prctl(). This stops sandboxed processes 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 —allow-sandbox-debugging option.

• Not all kernel versions support CLONE_NEWPID . If the SUID helper 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 does not restrict network access.
• This does not prevent processes within a given sandbox from sending each other signals or killing each other.
• Setting a process to be undumpable is not irreversible. A sandboxed process can make itself dumpable again, opening itself up to being taken over by another process (either unsandboxed or within the same sandbox).
  • Breakpad (the crash reporting tool) makes use of this. If a process crashes, Breakpad makes it dumpable in order to use ptrace() to halt threads and capture the process’s state at the time of the crash. This opens a small window of vulnerability.

This is an alternative to the CLONE_NEWPID method; it is not currently implemented in the Chromium codebase.

Instead of using CLONE_NEWPID , the 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 EAGAIN if 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.

• It is not possible for an unsandboxed process to ptrace() a sandboxed process because they run under different UIDs. This makes debugging harder. There is no equivalent of the —allow-sandbox-debugging other than turning the sandbox off with —no-sandbox .
• The SUID helper can check that a UID is unused before it uses it (hence this is safe if the SUID helper is installed into multiple chroots), but it cannot prevent other root processes from putting processes into this UID after the sandbox has been started. This means we should make the UID range configurable, or distributions should reserve a UID range.

The SUID helper uses CLONE_NEWNET to restrict network access.

We are splitting the SUID sandbox into a separate project which will support both the CLONE_NEWNS and setuid() methods: http://code.google.com/p/setuid-sandbox/

Having the SUID helper as a separate project should make it easier for distributions to review and package.

Источник