FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing

The viral analysis highlights a fundamental security divide in modern operating systems: FreeBSD's Capsicum and Linux's seccomp-bpf represent opposite philosophies for containing compromised processes. Capsicum, developed by Robert Watson and Jonathan Anderson at Cambridge University and integrated into FreeBSD 10.0 in 2014, takes a subtractive approach. The cap_enter() system call permanently removes all access to global namespaces—filesystem, network, process table—leaving only explicitly granted file descriptors with limited rights. There's no escape path because the attack surfaces simply cease to exist for the sandboxed process.

Linux's seccomp-bpf, introduced by Will Drewry in Linux 3.5 (2012), takes a filtration approach. Instead of removing access, it uses Berkeley Packet Filter (BPF) programs to inspect every system call at runtime, allowing administrators to create allowlists of permitted operations. While flexible and widely adopted (including by Docker), this approach maintains the process's ambient authority—the filter checks what the process attempts to do, not what resources it can access. The key distinction: Capsicum removes doors from the room, while seccomp hires a bouncer with a clipboard.

The practical implications are significant for security-critical applications. Capsicum's irreversible capability mode offers stronger guarantees against privilege escalation but requires careful upfront design. Seccomp-bpf provides more granular control and debugging capabilities but leaves the attack surface intact, requiring perfect filter rules. This philosophical divide explains why security researchers debate which approach better addresses the original Unix security model's limitations in an internet-connected world.