Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(109)

Unified Diff: docs/linux_sandboxing.md

Issue 1324603002: [Docs] Another round of stylistic fixes. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Created 5 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « docs/linux_sandbox_ipc.md ('k') | docs/linux_suid_sandbox.md » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: docs/linux_sandboxing.md
diff --git a/docs/linux_sandboxing.md b/docs/linux_sandboxing.md
index 00ba8dd8681414d0999b3e70f287dfe3139c7d5b..fb7cc73b74080e4194611ea1d7fc8690df8cd9ec 100644
--- a/docs/linux_sandboxing.md
+++ b/docs/linux_sandboxing.md
@@ -1,20 +1,41 @@
-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](http://dev.chromium.org/developers/design-documents/sandbox).
+# Linux Sandboxing
-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).
+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](http://dev.chromium.org/developers/design-documents/sandbox).
+
+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.
+* 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.
+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.
+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.
+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
@@ -31,67 +52,101 @@ Our layer-1 guarantees the integrity of processes running under different seccom
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.
+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).
+To disable it, use `--disable-setuid-sandbox`. (Do not remove the binary or
+unset `CHROME_DEVEL_SANDBOX`, it is not supported).
-_Main page: [LinuxSUIDSandbox](LinuxSUIDSandbox.md)_
+Main page: [LinuxSUIDSandbox](linux_suid_sandbox.md)
## User namespaces sandbox
-The namespace sandbox [aims to replace the setuid sandbox](https://code.google.com/p/chromium/issues/detail?id=312380). It has the advantage of not requiring a setuid binary. It's based on (unprivileged)
-[user namespaces](https://lwn.net/Articles/531114/) in the Linux kernel. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported.
+The namespace sandbox
+[aims to replace the setuid sandbox](https://crbug.com/312380). It has the
+advantage of not requiring a setuid binary. It's based on (unprivileged)
+[user namespaces](https://lwn.net/Articles/531114/) 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](https://code.google.com/p/chromium/issues/detail?id=460972), which isolates them better.
+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](https://crbug.com/460972), which isolates them
+better.
-## The <tt>seccomp-bpf</tt> sandbox
+## The `seccomp-bpf` sandbox
-Also called <tt>seccomp-filters</tt> sandbox.
+Also called `seccomp-filters` sandbox.
-Our main layer-2 sandbox, designed to shelter the kernel from malicious code executing in userland.
+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](http://www.tcpdump.org/papers/bpf-usenix93.pdf) 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.
+Also used as layer-1 in the GPU process. A
+[BPF](http://www.tcpdump.org/papers/bpf-usenix93.pdf) 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.
+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](http://outflux.net/teach-seccomp/) for more information.
+`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](http://outflux.net/teach-seccomp/) for more information.
-See [this blog post](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html) announcing Chrome support. Or [this one](http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html) for a more technical overview.
+See
+[this blog post](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html)
+announcing Chrome support. Or
+[this one](http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html)
+for a more technical overview.
-This sandbox can be disabled with --disable-seccomp-filter-sandbox.
+This sandbox can be disabled with `--disable-seccomp-filter-sandbox`.
-## The <tt>seccomp</tt> sandbox
+## The `seccomp` sandbox
-Also called <tt>seccomp-legacy</tt>. An obsolete layer-1 sandbox, then available as an optional layer-2 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](https://code.google.com/p/seccompsandbox/).
+Deprecated by seccomp-bpf and removed from the Chromium code base. It still
+exists as a separate project [here](https://code.google.com/p/seccompsandbox/).
See:
- * http://www.imperialviolet.org/2009/08/26/seccomp.html
- * http://lwn.net/Articles/346902/
- * https://code.google.com/p/seccompsandbox/
+
+* http://www.imperialviolet.org/2009/08/26/seccomp.html
+* http://lwn.net/Articles/346902/
+* https://code.google.com/p/seccompsandbox/
## SELinux
-[Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revision). Was designed to be used instead of the SUID sandbox.
+[Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revision).
+Was designed to be used instead of the SUID sandbox.
Old information for archival purposes:
-One can build Chromium with <tt>selinux=1</tt> and the Zygote (which starts the renderers and PPAPI processes) will do a
-dynamic transition. audit2allow will quickly build a usable module.
+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](http://src.chromium.org/viewvc/chrome?view=rev&revision=26257),
-more information in [this blog post](http://www.imperialviolet.org/2009/07/14/selinux.html) (grep for
-'dynamic' since dynamic transitions are a little obscure in SELinux)
+Available since
+[r26257](http://src.chromium.org/viewvc/chrome?view=rev&revision=26257),
+more information in
+[this blog post](http://www.imperialviolet.org/2009/07/14/selinux.html) (grep
+for 'dynamic' since dynamic transitions are a little obscure in SELinux)
## Developing and debugging with sandboxing
Sandboxing can make developing harder, see:
- * [this page](https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment) for the setuid sandbox
- * [this page](http://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs) for triggering crashes
- * [this page for debugging tricks](https://code.google.com/p/chromium/wiki/LinuxDebugging#Getting_renderer_subprocesses_into_gdb)
+
+* [this page](https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment)
+ for the `setuid` sandbox
+* [this page](http://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs)
+ for triggering crashes
+* [this page for debugging tricks](linux_debugging.md)
## See also
- * [LinuxSandboxIPC](LinuxSandboxIPC.md)
- * [How Chromium's Linux sandbox affects Native Client](https://code.google.com/p/nativeclient/wiki/LinuxOuterSandbox)
+
+* [LinuxSandboxIPC](linux_sandbox_ipc.md)
+* [How Chromium's Linux sandbox affects Native Client](https://code.google.com/p/nativeclient/wiki/LinuxOuterSandbox)
« no previous file with comments | « docs/linux_sandbox_ipc.md ('k') | docs/linux_suid_sandbox.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698