Using Seccomp to Limit the Kernel Attack Surface
summary
Explains how seccomp uses in-kernel BPF programs loaded via prctl or the seccomp syscall (and supported by libseccomp) to whitelist system calls and inspect up to six syscall arguments, with mandated checks of the architecture field and the no_new_privs requirement. Gives a concrete BPF filter that kills process on open (kernel makes the shell report "Bad system call"), notes filters are permanent, and reports performance: a six-instruction filter adds ~25% syscall cost on old kernels, reducible to ~6% with mitigations and ~2% with the JIT.
AI-written summary · about
chapters (31)
- 0:00Introduction
- 3:07History of Seccomp
- 5:04Seccomp Filtering
- 6:18Seccomp Filtering History
- 8:13How Seccomp Works
- 10:44Berkeley Packet Filter
- 13:17BPF Virtual Machine
- 17:17Conditional Jump Instructions
- 18:14Relative Offsets
- 18:49The Kernel
- 19:10System Call Data
- 22:28Example Load Instruction
- 24:29Example Conditional Jump
- 25:36Example Return Statement
- 26:14Architecture Field
- 29:27Answer the Filter
- 30:22Kill the Process
- 34:41Attacker
- 35:45Unprivileged User
- 36:20Example Program
- 39:37Filter Program Structure
- 40:01Running the Program
- 42:01BPA Filter Example
- 43:00A Word of Warning
- 44:35LibSetComp
- 45:48Multiple filters
- 48:25Two microphones
- 56:55Contacts
- 57:29SOC Camera
- 58:18SOC Glossary
- 59:04Seccomp Camera
related talks
52mUsing Seccomp to Limit the Kernel Attack Surface
01h 03mUsing seccomp to limit the Linux kernel attack service
28mUnderstanding programmable system call security with Secomp-eBPF in Linux.
01h 21mTutorial: The Why and How of libseccomp
44mSeccomp for Developers - Making Applications Simply More Secure
31mHandling New Syscalls in Seccomp Filters
32mDesigning to the Worst Case Scenario - Practical System Call Filtering with Seccomp
26mReinventing Seccomp for Fun and Profiles