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