seccomp: A Kernel-Level Allowlist for Syscalls

WHY IT EXISTS: Even a process running as a non-root user can access hundreds of powerful kernel system calls (syscalls). This creates a large attack surface. seccomp was created to enforce the principle of least privilege at the kernel level, reducing the potential damage a compromised process can do.

THE MENTAL MODEL: Think of seccomp as a one-way gate. A process can ask the kernel to activate a seccomp profile, which is an allowlist of syscalls. From that moment on, any attempt by the process to use a syscall NOT on the list causes the kernel to terminate the process. It's an enforcement mechanism, not just an audit tool.

HOW IT WORKS: A seccomp profile is a set of rules, typically defined in a JSON file, that specifies a default action (like SCMP_ACT_ERRNO to block) and a list of syscalls to permit. When a container starts, Docker (or the container runtime) loads this profile and applies it to the container's processes. The kernel then intercepts every syscall made by these processes, checks it against the loaded filter, and takes the specified action. Docker's default profile allows about 300 of the 400+ available syscalls, blocking those that are rarely needed and historically risky.

WHEN TO USE IT: Always use seccomp to harden containerized applications, especially those exposed to the network or processing untrusted input. It is a fundamental layer in defense-in-depth for containers and is enabled by default in Docker, Kubernetes, and other modern container platforms for this reason.

WHEN NOT TO USE IT: Avoid disabling the default profile unless an application legitimately needs a blocked syscall (e.g., for certain performance tracing or hardware interaction). Crafting custom profiles is powerful but risky; a profile that is too restrictive can cause applications to fail in obscure ways. Debugging a seccomp-related crash requires understanding which syscall is being blocked and why.

ONE CANONICAL EXAMPLE: A common privilege escalation technique involves creating a new user namespace inside a container via the unshare syscall. This can trick the host into granting the process root privileges. Docker's default seccomp profile explicitly blocks the unshare syscall. If an attacker gains access to a container and tries to run an exploit using this technique, the kernel will immediately terminate the malicious process, neutralizing the threat.