#CEF CHROME CODE#

A BPF compiler will compile a process-specific program to filter system calls and send it to the kernel.

#CEF CHROME CODE#

Our main layer-2 sandbox, designed to shelter the kernel from malicious code executing in userland.Īlso used as layer-1 in the GPU process. Starting with M-44, certain processes run in their own PID namespace, which isolates them better. Starting with M-43, if the kernel supports it, unprivileged namespaces are used instead of the setuid sandbox. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported. It's based on (unprivileged) user namespaces in the Linux kernel. It has the advantage of not requiring a setuid binary. The namespace sandbox aims to replace the setuid sandbox. Main page: LinuxSUIDSandbox User namespaces sandbox (Do not remove the binary or unset CHROME_DEVEL_SANDBOX, it is not supported).

To disable it, use -disable-setuid-sandbox. Outer layer-1 in Zygote processes (renderers, PPAPI)Īlso called SUID sandbox, our main layer-1 sandbox.Ī SUID binary that will create a new network and PID namespace, as well as chroot() the process to an empty directory on request.

Layer-1 in Zygote processes (renderers, PPAPI) Linux kernel >= 3.5, Chrome OS and UbuntuĮnabled by default and actively developed Layer-2 in some Zygote processes (renderers, PPAPI, NaCl), Layer-1 + Layer-2 in GPU process Linux distributions and Chrome OS (kernel >= 3.8)Įnabled by default (modern kernels) and actively developed Layer-1 in Zygote processes (renderers, PPAPI, NaCl, some utility processes) Modern alternative to the setuid sandbox. Layer-1 in Zygote processes (renderers, PPAPI, NaCl, some utility processes)Įnabled by default (old kernels) and maintained 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. 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 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). One notable difficulty with seccomp-bpf is that filtering at the system call interface provides difficult to understand semantics. You can disable all sandboxing (for testing) with -no-sandbox. Layer-2 (also called “attack surface reduction” layer) restricts access from a process to the attack surface of the kernel.Layer-1 (also called the “semantics” layer) prevents access to most resources from a process where it's engaged.You can see which sandboxes are currently engaged by looking at chrome://sandbox (renderer processes) and chrome://gpu (gpu process). We use different sandboxing techniques on Linux and Chrome OS, in combination, to achieve a good level of sandboxing. You can find more about this general design here. Renderers will use an IPC mechanism to request access to resource from a more privileged (browser process). For instance, we want renderers to run with a limited set of privileges since they process untrusted input and are likely to be compromised. Chromium uses a multiprocess model, which allows to give different privileges and restrictions to different parts of the browser.

Cef chrome