AI
Why Seccomp Profiles Are Hard to Get Right
Manning profiled a hello world program. Outside a container it emitted 170 system calls. Inside a container it emitted 1,811. The difference comes from the container runtime itself. Tools like strace, Inspector Gadget, and kubectl trace all gave different results for the same 100 images. One run of hello world captured BPF system calls, which would allow a rootkit. The default Kubernetes seccomp profile already blocks dangerous syscalls. Custom profiles often add them back.
The Three Perils of System Call Filtering
Manning identified three failure modes. First, missing a system call crashes the container. The container crashes in production. Second, capturing unrelated syscalls from sidecars or monitoring agents like Falco. Those syscalls get allowed by the profile. Third, applications like MongoDB try io_uring. Here’s the full bypass. sec goal.
Measuring Seccomp Effectiveness with sec-compare
Manning built sec-compare and sec-compute, open-source tools. They compare a custom seccomp profile against the default runtime profile. The analysis measures two dimensions: how many benign syscalls are allowed and how many dangerous ones. On the sliding scale, “lawful good” profiles drop BPF and ptrace. “Chaotic evil” profiles allow more of both. Manning ran profiles from real organizations and found many custom profiles were worse than default.
When Seccomp Fails: The io_uring Bypass
MongoDB and other databases multiplex system calls into a bundle of system calls into a single io_uring syscall. Manning demonstrated a netcat-like connection blocked by seccomp. He rewrote it to use io_uring only. The connection succeeded despite a profile blocking socket, bind, and listen. Seccomp never saw the multiplexed calls. This is a practical bypass for any workload using io_uring, and the default profile does not block it.
Beyond Seccomp: MicroVMs and gVisor
Manning argued that a hypervisor is the strongest security boundary. Containers removed it. Sandbox runtimes like gVisor put a hypervisor back inside each container. gVisor emulates the kernel, so a container breakout must also escape the emulated layer. It works without nested virtualization. Kata Containers and Firecracker take a similar approach. For high-performance environments, custom seccomp still has a use case, but only with heavy investment.
Q&A
Can these tools intercept direct syscalls that bypass libc trampolines? Seccomp intercepts at the kernel level, not inline. Inline interception requires eBPF and faces time-of-check time-of-use problems. ▶ Watch (42:17)
Is there a CLI version of sec-compare? Yes, sec-compute is a command-line tool that can analyze any seccomp profile. ▶ Watch (42:56)
Notable Quotes
so one of the things that um SEC compare does is better comparing to the default one Mark Manning · ▶ Watch (24:30)
io_uring is a completely different one. so when you multiplex them together, you know, you’ve got this scenario of okay, I’m attempting to block socket bind and listen, right? But then I go through and I say, “Hey, uh, I’ve accidentally allowed IOU ring and like oops or like maybe there’s a default accept.” Mark Manning · ▶ 31:15
one is none and two is one Mark Manning · ▶ 40:54
practical complexity is a peacetime disease Mark Manning · ▶ 40:08
Key Takeaways
- Custom seccomp profiles often add dangerous syscalls and are worse than the default.
- System call tracing tools introduce noise from sidecars and fault a profile’s contents.
- io_uring can bypass seccomp filters that block individual socket calls.
- gVisor and microVMs provide a stronger isolation boundary than seccomp alone.
- Measure every seccomp profile with sec-compare before deploying.
About the Speaker(s)
Mark Manning (@antitree) is part of the security team at Chainguard, a secure software supply chain company where he is researching how we securely run and build containers. He’s spent years as a security researcher and penetration tester presenting at DEFCON, Shmoocon, B-Sides’ sharing.