Security/Sandbox/Seccomp
What is Seccomp
Intro to seccomp and seccomp-bpf
Seccomp stands for secure computing mode. It's a simple sandboxing tool in the Linux kernel, available since Linux version 2.6.12. When enabling seccomp, the process enters a "secure mode" where a very small number of system calls are available (exit(), read(), write(), sigreturn()). Writing code to work in this environment is difficult; for example, dynamic memory allocation (using brk() or mmap(), either directly or to implement malloc()) is not possible.
Seccomp-BPF is a more recent extension to seccomp, which allows filtering system calls with BPF (Berkeley Packet Filter) programs. These filters can be used to allow or deny an arbitrary set of system calls, as well as filter on system call arguments (numeric values only; pointer arguments can't be dereferenced). Additionally, instead of simply terminating the process, the filter can raise a signal, which allows the signal handler to simulate the effect of a disallowed system call (or simply gather more information on the failure for debugging purposes). Seccomp-bpf is available since Linux version 3.5 and is usable on the ARM architecture since Linux version 3.10. Several backports are available for earlier kernel versions.
We have backports for 3.0.x kernels, 3.4 kernels, and 2.6.29 kernels (see bug 790923 and its children). No backport is necessary for kernels 3.10 and above. These configuration options are required to be present in the kernel's config at compile time:
CONFIG_SECCOMP=y CONFIG_SECCOMP_FILTER=y
How do I call seccomp-bpf ?
Seccomp-bpf is turned on through the prctl() system call (process control), like this:
#include <sys/prctl.h> #include <linux/seccomp.h> [...] prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &bpf_prog)
bpf_prog is a BPF structure which contains the rules used by seccomp-bpf — i.e., which system calls are allowed or not. To ensure that you can't execute this call again with a more permissive filter program (bpf_prog), there is an additional call to make, "no new privileges", which ensures it's only possible to tighten the filter, never to extend it. This means you could first remove access to one system call, then later on in the process lifetime, remove access to more system calls, for example. Here's the same code, with the no new privileges call:
#include <sys/prctl.h> #include <linux/seccomp.h> [...] prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &bpf_prog)
Construct a basic filter
The filter program can be constructed using BPF filter macros, which are listed in linux's filter.h. Here's a list of commonly used macros for seccomp-bpf:
#include <linux/filter.h>
[...]
#define syscall_nr (offsetof(struct seccomp_data, nr))
#define arch_nr (offsetof(struct seccomp_data, arch))
#define VALIDATE_ARCHITECTURE \
BPF_STMT(BPF_LD+BPF_W+BPF_ABS, arch_nr), \
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ARCH_NR, 1, 0), \
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL)
#define EXAMINE_SYSCALL \
BPF_STMT(BPF_LD+BPF_W+BPF_ABS, syscall_nr)
#define ALLOW_SYSCALL(name) \
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_##name, 0, 1), \
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW)
#define KILL_PROCESS \
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL)
In this example, you could have a filter that validates that the syscall is for the correct architecture (rather than trying to invoke an OS-emulation feature or 32/64-bit translation, where the syscall numbers could have different meanings), then check the syscall number against each entry on a whitelist and allow the call if it matches, and finally kill the process if it didn't match any whitelist entry.
Complex filters
The BPF language doesn't allow loops (branches can only skip instructions, not jump back), but more complex computations than a simple whitelist check are possible. For example, the Chromium codebase contains modules that translate a more abstract representation of filter predicates (ErrorCode) into a basic block graph and then into a linear sequence of BPF instructions (CodeGen); this includes constructing a binary search tree to dispatch on the system call number in O(log n) time.
It is also possible to implement a "warn-only" mode by having the filter program check the instruction pointer (program counter) and allow all syscalls where the machine instruction that performed the call is at a specific address. This way, if a syscall would have been rejected, it instead raises SIGSYS and the signal handler logs the syscall before re-issuing it by jumping to the always-allowed syscall gate. This offers basically no security, as an attacker who compromises the process could issue arbitrary syscalls by jumping to that location, but it can simplify testing and developing a sandbox policy.
Use in Gecko
Gecko on the desktop and in B2G use seccomp when running on Linux. The code is in mozilla-central at /security/sandbox/linux.
File security/sandbox/linux/seccomp_filter.h
Contains a whitelist of allowed system calls.
File security/sandbox/linux/Sandbox.cpp
Contains the sandbox installation code, called by:
SetCurrentProcessSandbox(void)
Seccomp reporter
The reporter is an option which will log exactly which system call has been denied by seccomp. It is enabled by default in engineering builds ("eng" builds). The option is --content-sandbox-reporter.
When seccomp denies a system call, it sends a signal (SIGSYS) which is caught by the reporter. The reporter then kills itself (and thus the content-process). The report kill itself because the content process may not handle the denied system call properly and be in a non-working state anyway.
When the reporter is enabled, the log message looks like this:
seccomp sandbox violation: pid %u, syscall %lu, args %lu %lu %lu %lu %lu. Killing Process.
How do I check my processes are sandboxed by seccomp?
There is a seccomp flag in the process status:
Replace <pid> by the process's PID.
grep Seccomp /proc/<pid>/status
- 0: Seccomp is not enabled (bad!)
- 1: Seccomp is enabled (shouldn't happen)
- 2: Seccomp-bpf is enabled (correct)
Alternatively, on recent (1.4+) b2g versions:
- b2g-ps, look at the SEC field (same meanings as above, 2 means sandboxed)
On B2G, you can find out your PIDs by using the command b2g-ps
How do I disable the sandbox temporarily?
export MOZ_DISABLE_CONTENT_SANDBOX=1
and restart Firefox. In B2G's case, this looks like:
adb shell stop b2g export MOZ_DISABLE_CONTENT_SANDBOX=1 /system/bin/b2g.sh
More information
See also the kernel documentation: