Using Seccomp to Limit the Kernel Attack Surface
summary
Seccomp uses BPF programs to whitelist or block kernel calls, reducing a 400-call kernel surface to the small set an app actually needs — typical apps uses <40 syscalls — and can kill or return errno for unexpected calls. Filters are per-process, permanent, expressed as BPF (only read-only syscall numbers/args, no pointer dereference yet) and limited to 4k-instruction filter / 32k total across all filters; installation via prctl or the newer seccomp syscall, often generated with libseccomp API. Expect measurable overhead (example: getppid +25%) and brittleness from libc/ABI changes (open→openat).
AI-written summary · about
chapters (33)
- 0:00Intro
- 0:19What is Seccomp
- 0:29System calls
- 2:26Seccomp history
- 4:30Filter mode
- 5:15System call limitation
- 7:19Seccomp
- 8:02Second Filtering
- 12:58BPF
- 15:48Virtual Machine
- 18:27Conditional Jump Instructions
- 19:39Relative Offsets
- 20:25System Call Structure
- 22:22BPF Statement
- 25:11BPF Jump
- 26:06BPF Return
- 26:46ADD
- 27:30Architecture
- 27:45System Call Numbers
- 28:58System Call Conventions
- 32:55Filter Program
- 35:17Example
- 41:22Performance Cost
- 43:28Which System Causes My Application Make
- 44:09What About That
- 44:51System Call Filtering
- 45:59Lubeset Comp
- 46:41Seccomp Context
- 47:29BPF Compiler
- 47:49JIT Compiler
- 48:49Applications
- 49:54Further Information
- 50:12Questions
related talks
01h 29mUsing 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.
32mDesigning to the Worst Case Scenario - Practical System Call Filtering with Seccomp
44mSeccomp for Developers - Making Applications Simply More Secure
01h 21mTutorial: The Why and How of libseccomp
31mHandling New Syscalls in Seccomp Filters
26mReinventing Seccomp for Fun and Profiles