Using Seccomp to Limit the Kernel Attack Surface - Michael Kerrisk, man7.org Training and Consulting

Michael Kerrisk presents seccomp (secure computing mode) as a mechanism to reduce kernel attack surface by restricting which system calls a process can execute. The Linux kernel provides approximately 400 system calls, but most programs use only a small subset (typically around 40). Seccomp allows administrators to define filters that prevent processes from making unexpected system calls, stopping malicious code from exploiting the full kernel API.

Kerrisk traces seccomp's evolution: strict mode (2005, limiting processes to read, write, exit, and signal handling) and seccomp 2 (2012, introducing configurable BPF-based filtering). The modern approach uses Berkeley Packet Filter (BPF), a virtual machine originally designed for network packet filtering in tcpdump, now repurposed for inspecting system call numbers and arguments.

The BPF virtual machine has specific design features ensuring safety: a simple instruction set, forward-only jumps (preventing infinite loops), and kernel verification of program validity. Filters can inspect system call numbers and register values (arguments), though they cannot dereference pointers. Return values from filters indicate actions: allow the system call, kill the process, kill the thread, or fail the call with a specified errno.

Kerrisk demonstrates practical examples using sock_filter structures, showing how to check architecture (critical because system call numbers differ across x86, ARM, etc.) and allow/deny specific calls like open(). He emphasizes that seccomp filters are permanent once installed and cannot be removed. The performance overhead is measurable but acceptable, especially with modern mitigations and JIT compilation.

Key challenges include determining which system calls a program actually makes and maintaining filters through continuous integration testing, as incorrect filters cause application crashes. Tools like libseccomp provide higher-level APIs for filter construction, abstracting away low-level BPF details. The mechanism is widely adopted in modern systems (web browsers, container frameworks, systemd), though careful testing remains essential due to the inherent fragility of system call filtering.