OLD | NEW |
(Empty) | |
| 1 Chromium uses a multiprocess model, which allows to give different privileges an
d restrictions to different parts of the browser. For instance, we want renderer
s 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 ac
cess to resource from a more privileged (browser process). |
| 2 You can find more about this general design [here](http://dev.chromium.org/devel
opers/design-documents/sandbox). |
| 3 |
| 4 We use different sandboxing techniques on Linux and Chrome OS, in combination, t
o achieve a good level of sandboxing. You can see which sandboxes are currently
engaged by looking at chrome://sandbox (renderer processes) and chrome://gpu (gp
u process). |
| 5 |
| 6 We have a two layers approach: |
| 7 |
| 8 * Layer-1 (also called the "semantics" layer) prevents access to most resource
s from a process where it's engaged. The setuid sandbox is used for this. |
| 9 * 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. |
| 10 |
| 11 You can disable all sandboxing (for testing) with --no-sandbox. |
| 12 |
| 13 ## Layered approach |
| 14 |
| 15 One notable difficulty with seccomp-bpf is that filtering at the system call int
erface 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 w
ould 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. |
| 16 |
| 17 Our layer-1 guarantees the integrity of processes running under different seccom
p-bpf policies. In addition, it allows restricting access to the network, someth
ing that is difficult to perform at the layer-2. |
| 18 |
| 19 ## Sandbox types summary |
| 20 |
| 21 | **Name** | **Layer and process** | **Linux flavors where available** | **State
** | |
| 22 |:---------|:----------------------|:----------------------------------|:-------
---| |
| 23 | [Setuid sandbox](#The_setuid_sandbox.md) | Layer-1 in Zygote processes (render
ers, PPAPI, [NaCl](http://www.chromium.org/nativeclient), some utility processes
) | Linux distributions and Chrome OS | Enabled by default (old kernels) and mai
ntained | |
| 24 | [User namespaces sandbox](#User_namespaces_sandbox.md) | Modern alternative to
the setuid sandbox. Layer-1 in Zygote processes (renderers, PPAPI, [NaCl](http:
//www.chromium.org/nativeclient), some utility processes) | Linux distributions
and Chrome OS (kernel >= 3.8) | Enabled by default (modern kernels) and actively
developed | |
| 25 | [Seccomp-BPF](#The_seccomp-bpf_sandbox.md) | Layer-2 in some Zygote processes
(renderers, PPAPI, [NaCl](http://www.chromium.org/nativeclient)), Layer-1 + Laye
r-2 in GPU process | Linux kernel >= 3.5, Chrome OS and Ubuntu | Enabled by defa
ult and actively developed | |
| 26 | [Seccomp-legacy](#The_seccomp_sandbox.md) | Layer-2 in renderers | All
| [Deprecated](https://src.chromium.org/viewvc/chrome?re
vision=197301&view=revision) | |
| 27 | [SELinux](#SELinux.md) | Layer-1 in Zygote processes (renderers, PPAPI) | SELi
nux distributions | [Deprecated](https://src.chromium.org/viewvc/chr
ome?revision=200838&view=revision) | |
| 28 | Apparmor | Outer layer-1 in Zygote processes (renderers, PPAPI) | Not used
| Deprecated | |
| 29 |
| 30 ## The setuid sandbox |
| 31 |
| 32 Also called SUID sandbox, our main layer-1 sandbox. |
| 33 |
| 34 A SUID binary that will create a new network and PID namespace, as well as chroo
t() the process to an empty directory on request. |
| 35 |
| 36 To disable it, use --disable-setuid-sandbox. (Do not remove the binary or unset
CHROME\_DEVEL\_SANDBOX, it is not supported). |
| 37 |
| 38 _Main page: [LinuxSUIDSandbox](LinuxSUIDSandbox.md)_ |
| 39 |
| 40 ## User namespaces sandbox |
| 41 |
| 42 The namespace sandbox [aims to replace the setuid sandbox](https://code.google.c
om/p/chromium/issues/detail?id=312380). It has the advantage of not requiring a
setuid binary. It's based on (unprivileged) |
| 43 [user namespaces](https://lwn.net/Articles/531114/) in the Linux kernel. It gene
rally requires a kernel >= 3.10, although it may work with 3.8 if certain patche
s are backported. |
| 44 |
| 45 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 the
ir own PID namespace](https://code.google.com/p/chromium/issues/detail?id=460972
), which isolates them better. |
| 46 |
| 47 ## The <tt>seccomp-bpf</tt> sandbox |
| 48 |
| 49 Also called <tt>seccomp-filters</tt> sandbox. |
| 50 |
| 51 Our main layer-2 sandbox, designed to shelter the kernel from malicious code exe
cuting in userland. |
| 52 |
| 53 Also used as layer-1 in the GPU process. A [BPF](http://www.tcpdump.org/papers/b
pf-usenix93.pdf) compiler will compile a process-specific program |
| 54 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. |
| 55 |
| 56 To help with sandboxing of existing code, the kernel can also synchronously rais
e a SIGSYS signal. This allows user-land to perform actions such as "log and ret
urn errno", emulate the system call or broker-out the system call (perform a rem
ote system call via IPC). Implementing this requires a low-level async-signal sa
fe IPC facility. |
| 57 |
| 58 Seccomp-bpf is supported since Linux 3.5, but is also back-ported on Ubuntu 12.0
4 and is always available on Chrome OS. See [this page](http://outflux.net/teach
-seccomp/) for more information. |
| 59 |
| 60 See [this blog post](http://blog.chromium.org/2012/11/a-safer-playground-for-you
r-linux-and.html) announcing Chrome support. Or [this one](http://blog.cr0.org/2
012/09/introducing-chromes-next-generation.html) for a more technical overview. |
| 61 |
| 62 This sandbox can be disabled with --disable-seccomp-filter-sandbox. |
| 63 |
| 64 ## The <tt>seccomp</tt> sandbox |
| 65 |
| 66 Also called <tt>seccomp-legacy</tt>. An obsolete layer-1 sandbox, then available
as an optional layer-2 sandbox. |
| 67 |
| 68 Deprecated by seccomp-bpf and removed from the Chromium code base. It still exis
ts as a separate project [here](https://code.google.com/p/seccompsandbox/). |
| 69 |
| 70 See: |
| 71 * http://www.imperialviolet.org/2009/08/26/seccomp.html |
| 72 * http://lwn.net/Articles/346902/ |
| 73 * https://code.google.com/p/seccompsandbox/ |
| 74 |
| 75 ## SELinux |
| 76 |
| 77 [Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revisio
n). Was designed to be used instead of the SUID sandbox. |
| 78 |
| 79 Old information for archival purposes: |
| 80 |
| 81 One can build Chromium with <tt>selinux=1</tt> and the Zygote (which starts the
renderers and PPAPI processes) will do a |
| 82 dynamic transition. audit2allow will quickly build a usable module. |
| 83 |
| 84 Available since [r26257](http://src.chromium.org/viewvc/chrome?view=rev&revision
=26257), |
| 85 more information in [this blog post](http://www.imperialviolet.org/2009/07/14/se
linux.html) (grep for |
| 86 'dynamic' since dynamic transitions are a little obscure in SELinux) |
| 87 |
| 88 ## Developing and debugging with sandboxing |
| 89 |
| 90 Sandboxing can make developing harder, see: |
| 91 * [this page](https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopm
ent) for the setuid sandbox |
| 92 * [this page](http://www.chromium.org/for-testers/bug-reporting-guidelines/han
ging-tabs) for triggering crashes |
| 93 * [this page for debugging tricks](https://code.google.com/p/chromium/wiki/Lin
uxDebugging#Getting_renderer_subprocesses_into_gdb) |
| 94 |
| 95 ## See also |
| 96 * [LinuxSandboxIPC](LinuxSandboxIPC.md) |
| 97 * [How Chromium's Linux sandbox affects Native Client](https://code.google.com
/p/nativeclient/wiki/LinuxOuterSandbox) |
OLD | NEW |