HeadlinesBriefing favicon HeadlinesBriefing.com

FreeBSD Capsicum vs Linux seccomp: Two Paths to Process Sandboxing

Hacker News •
×

Unix systems have long struggled with the ambient authority problem, where compromised processes inherit full user privileges. FreeBSD tackled this with Capsicum, a capability-based sandboxing model that removes all access and grants only what's explicitly needed. Introduced in 2010 and compiled into FreeBSD 10.0 by default in 2014, Capsicum uses a simple API: cap_enter() irreversibly restricts the process to only its existing file descriptors with defined rights.

Linux took a different approach with seccomp-bpf, implemented in 2012. Rather than removing access, it filters syscalls through a BPF program that checks each system call at runtime. While effective, this filtration model means processes retain full ambient authority - an allowed read() can access any open file descriptor. Docker's default seccomp profile blocks approximately 44 of 300+ syscalls, leaving 256 potentially dangerous calls unfiltered.

The architectural difference becomes clear in real-world applications. Chromium uses Capsicum on FreeBSD, where renderer processes call cap_enter() after opening needed resources, creating a sandbox that's structurally secure regardless of kernel changes. On Linux, Chromium combines seccomp-bpf with namespaces, requiring ongoing maintenance as new syscalls are added. This fundamental distinction - subtraction versus filtration - defines how each system handles process isolation.