Chrome Seccomp Sandbox Continues To Improve

The Chrome seccomp sandbox works by limiting Chrome’s access to system calls by including a whitelist at compile time. This feature is supported in all Linux kernels 3.5 and up, as well as some specific distros like Ubuntu. Chrome is one of a few programs to make use of this new sandbox but hopefully we see this become mainstream. The concept is built around limiting the kernel’s exposure to the system – if you limit how a program can interact with the kernel you limit it’s potential to exploit the kernel.

Chrome released it’s BPF Mode 2 Seccomp Filters sandbox for Linux a few months ago but it’s not done. As I explain on my post about system calls the call itself is made up of the call as well as an argument. A new commit to Chromium provides the ability to filter based on the arguments (as I understand, it could just be for auditing), as well as the system call, which, again, limits interaction to the kernel. This commit is likely part of future work to implement this, and it may not yet be functional, if I’m even interpreting it correctly, which I may not be. If I’m wrong just think about how cool it wouldbe as opposed to how cool it willbe.

  // Evaluate the BPF program for all possible inputs and verify that it
  // computes the correct result. We use the "evaluators" to determine
  // the full set of possible inputs that we have to iterate over.
  // Returns success, if the BPF filter accurately reflects the rules
  // set by the "evaluators".

  // We are testing SandboxSyscall() by making use of a BPF filter that allows us
  // to inspect the system call arguments that the kernel saw.

One easy to look at example of how this would prevent exploits is the brk vulnerability (read about this vulnerability, trust me), where do_brk() didn’t perform proper bounds checking, and allowed for privilege escalation. A program like Chrome may need access to a system call, like do_berk(), and given such access it could then exploit the kernel. But if you validated how do_berk() could be called you could prevent this vulnerability from being exploited entirely. There are many known vulnerabilities that could potentially be stopped through whitelisting/ validating parameters.

Essentially you would limit two things:

1) What parts of the kernel can be interacted with (how seccomp has always worked)

2) Howthose specific parts can be interacted with (what this patch seems to imply)

If this is indeed the direction they’re headed it makes this already powerful sandbox far more comprehensive.

More solid reading:

https://www.cr0.org/paper/to-jt-party-at-ring0.pdf Classic paper. One really important point made is that kernel attack surface keeps growing, so if you allow it arbitrary access a userland process will only ever increase its abilities to escalate privileges – access control is necessary.