1# Linux Sandboxing 2 3Chromium uses a multiprocess model, which allows to give different privileges 4and restrictions to different parts of the browser. For instance, we want 5renderers to run with a limited set of privileges since they process untrusted 6input and are likely to be compromised. Renderers will use an IPC mechanism to 7request access to resource from a more privileged (browser process). 8You can find more about this general design 9[here](https://dev.chromium.org/developers/design-documents/sandbox). 10 11We use different sandboxing techniques on Linux and Chrome OS, in combination, 12to achieve a good level of sandboxing. You can see which sandboxes are currently 13engaged by looking at chrome://sandbox (renderer processes) and chrome://gpu 14(gpu process). 15 16We have a two layers approach: 17 18* Layer-1 (also called the "semantics" layer) prevents access to most 19 resources from a process where it's engaged. The setuid sandbox is used for 20 this. 21* Layer-2 (also called "attack surface reduction" layer) restricts access from 22 a process to the attack surface of the kernel. Seccomp-BPF is used for this. 23 24You can disable all sandboxing (for testing) with `--no-sandbox`. 25 26## Layered approach 27 28One notable difficulty with `seccomp-bpf` is that filtering at the system call 29interface provides difficult to understand semantics. One crucial aspect is that 30if a process A runs under `seccomp-bpf`, we need to guarantee that it cannot 31affect the integrity of process B running under a different `seccomp-bpf` policy 32(which would be a sandbox escape). Besides the obvious system calls such as 33`ptrace()` or `process_vm_writev()`, there are multiple subtle issues, such as 34using `open()` on `/proc` entries. 35 36Our layer-1 guarantees the integrity of processes running under different 37`seccomp-bpf` policies. In addition, it allows restricting access to the 38network, something that is difficult to perform at the layer-2. 39 40## Sandbox types summary 41 42| **Name** | **Layer and process** | **Linux flavors where available** | **State** | 43|:---------|:----------------------|:----------------------------------|:----------| 44| [Setuid sandbox](#The-setuid-sandbox) | Layer-1 in Zygote processes (renderers, PPAPI, [NaCl](https://www.chromium.org/nativeclient), some utility processes) | Linux distributions and Chrome OS | Enabled by default (old kernels) and maintained | 45| [User namespaces sandbox](#User-namespaces-sandbox) | Modern alternative to the setuid sandbox. Layer-1 in Zygote processes (renderers, PPAPI, [NaCl](https://www.chromium.org/nativeclient), some utility processes) | Linux distributions and Chrome OS (kernel >= 3.8) | Enabled by default (modern kernels) and actively developed | 46| [Seccomp-BPF](#The-sandbox-1) | Layer-2 in some Zygote processes (renderers, PPAPI, [NaCl](https://www.chromium.org/nativeclient)), Layer-1 + Layer-2 in GPU process | Linux kernel >= 3.5, Chrome OS and Ubuntu | Enabled by default and actively developed | 47| [Seccomp-legacy](#The-sandbox-2) | Layer-2 in renderers | All | [Deprecated](https://src.chromium.org/viewvc/chrome?revision=197301&view=revision) | 48| [SELinux](#SELinux) | Layer-1 in Zygote processes (renderers, PPAPI) | SELinux distributions | [Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revision) | 49| AppArmor | Outer layer-1 in Zygote processes (renderers, PPAPI) | Not used | Deprecated | 50 51## The setuid sandbox 52 53Also called SUID sandbox, our main layer-1 sandbox. 54 55A SUID binary that will create a new network and PID namespace, as well as 56`chroot()` the process to an empty directory on request. 57 58To disable it, use `--disable-setuid-sandbox`. (Do not remove the binary or 59unset `CHROME_DEVEL_SANDBOX`, it is not supported). 60 61Main page: [LinuxSUIDSandbox](suid_sandbox.md) 62 63## User namespaces sandbox 64 65The namespace sandbox 66[aims to replace the setuid sandbox](https://crbug.com/312380). It has the 67advantage of not requiring a setuid binary. It's based on (unprivileged) 68[user namespaces](https://lwn.net/Articles/531114/) in the Linux kernel. It 69generally requires a kernel >= 3.10, although it may work with 3.8 if certain 70patches are backported. 71 72Starting with M-43, if the kernel supports it, unprivileged namespaces are used 73instead of the setuid sandbox. Starting with M-44, certain processes run 74[in their own PID namespace](https://crbug.com/460972), which isolates them 75better. 76 77## The `seccomp-bpf` sandbox 78 79Also called `seccomp-filters` sandbox. 80 81Our main layer-2 sandbox, designed to shelter the kernel from malicious code 82executing in userland. 83 84Also used as layer-1 in the GPU process. A 85[BPF](http://www.tcpdump.org/papers/bpf-usenix93.pdf) compiler will compile a 86process-specific program to filter system calls and send it to the kernel. The 87kernel will interpret this program for each system call and allow or disallow 88the call. 89 90To help with sandboxing of existing code, the kernel can also synchronously 91raise a `SIGSYS` signal. This allows user-land to perform actions such as "log 92and return errno", emulate the system call or broker-out the system call 93(perform a remote system call via IPC). Implementing this requires a low-level 94async-signal safe IPC facility. 95 96`seccomp-bpf` is supported since Linux 3.5, but is also back-ported on Ubuntu 9712.04 and is always available on Chrome OS. See 98[this page](http://outflux.net/teach-seccomp/) for more information. 99 100See 101[this blog post](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html) 102announcing Chrome support. Or 103[this one](http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html) 104for a more technical overview. 105 106This sandbox can be disabled with `--disable-seccomp-filter-sandbox`. 107 108## The `seccomp` sandbox 109 110Also called `seccomp-legacy`. An obsolete layer-1 sandbox, then available as an 111optional layer-2 sandbox. 112 113Deprecated by seccomp-bpf and removed from the Chromium code base. It still 114exists as a separate project [here](https://code.google.com/p/seccompsandbox/). 115 116See: 117 118* http://www.imperialviolet.org/2009/08/26/seccomp.html 119* http://lwn.net/Articles/346902/ 120* https://code.google.com/p/seccompsandbox/ 121 122## SELinux 123 124[Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revision). 125Was designed to be used instead of the SUID sandbox. 126 127Old information for archival purposes: 128 129One can build Chromium with `selinux=1` and the Zygote (which starts the 130renderers and PPAPI processes) will do a dynamic transition. audit2allow will 131quickly build a usable module. 132 133Available since 134[r26257](https://src.chromium.org/viewvc/chrome?view=rev&revision=26257), 135more information in 136[this blog post](http://www.imperialviolet.org/2009/07/14/selinux.html) (grep 137for 'dynamic' since dynamic transitions are a little obscure in SELinux) 138 139## Developing and debugging with sandboxing 140 141Sandboxing can make developing harder, see: 142 143* [this page](suid_sandbox_development.md) for the `setuid` sandbox 144* [this page](https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs) 145 for triggering crashes 146* [this page for debugging tricks](debugging.md) 147 148## See also 149 150* [LinuxSandboxIPC](sandbox_ipc.md) 151* [How Chromium's Linux sandbox affects Native Client](https://chromium.googlesource.com/native_client/src/native_client.git/+/master/docs/outer_sandbox.md) 152