Hardening Containers with Seccomp: Hands-On Profiles, Pitfalls, and Real Exploits

Seccomp is a Linux kernel feature for filtering system calls, dating back about two decades. The speaker traces its origins to sandboxing browsers, then to container runtimes that adopted a simpler JSON profile format. Docker applies a default profile, while Kubernetes initially left seccomp off, so most clusters rarely use it. The main obstacle is that developers often cannot say which system calls their applications need.

A live comparison showed an unconfined NGINX container able to create namespaces and access the kernel keyring, while a container with the default profile was blocked from both and kept serving traffic. The main case study targets a server-side template injection flaw in a change-detection application that leads to code execution and theft of a Kubernetes service account token. An eBPF-based node agent recorded the syscalls the workload made, and those were converted into an application profile and applied to the deployment. When the exploit was replayed, it failed partway through because it needed a call the profile did not allow.

The closing discussion covered trade-offs. Profiles are blunt, can break functionality if observed behavior is incomplete, and may record malicious activity during learning, so generating them in staging and reviewing them in version control was advised. Alternatives such as AppArmor, SELinux and Landlock are harder to fit into containers. The speaker also argued that seccomp can extend the patching window for known CVEs, though its effect on any given vulnerability is not guaranteed.