seccomp listeners for nested containers
summary
Kernel currently restricts seccomp listeners to single listener per process even though filters are nested; this patchset proposes letting listeners be nested by walking listeners from the lowest to the root and honoring SECCOMP_FILTER_FLAG_NEW_LISTENER semantics while preserving the current behavior when a historical listener was closed. The code distinguishes allocated-vs-loaded-only listeners, tracks the historically first listener, and avoids fastpath slowdown by re-evaluating filters only when the final verdict is user notification; a three-version patchset is on LKML.
AI-written summary · about
chapters (15)
- 0:00Introduction and background
- 1:05Seccomp filter modes overview
- 3:42How seccomp filters execute
- 5:51User notify and syscall emulation
- 7:39Nested containers use case
- 8:00Current nesting limitation
- 9:04Naive approach and challenges
- 11:52Pitfalls in nested listener handling
- 15:51Equivalent code snippets behavior
- 17:39Victim process syscall flow
- 19:47Handling multiple notify programs
- 21:15Tracking listener states
- 22:38Discussion on current behavior
- 24:41Performance considerations
- 26:48Summary and acknowledgments
related talks
19mSeecomp
35mRevisiting eBPF Seccomp Filters
31mHandling New Syscalls in Seccomp Filters
01h 29mUsing Seccomp to Limit the Kernel Attack Surface
26mReinventing Seccomp for Fun and Profiles
52mUsing Seccomp to Limit the Kernel Attack Surface
01h 03mUsing seccomp to limit the Linux kernel attack service
32mDesigning to the Worst Case Scenario - Practical System Call Filtering with Seccomp