seccomp Syscall Filtering

seccomp and seccomp-BPF for syscall filtering in containers, Docker default profiles, and writing custom filters.

Overview

seccomp (Secure Computing Mode) is a Linux kernel feature that restricts which system calls a process can make. It is the primary attack-surface-reduction mechanism used by Docker, Kubernetes, and browsers (Chrome/Firefox sandbox).

Modes

SECCOMP_MODE_STRICT — allows only read, write, exit, and sigreturn. Rarely used directly.
SECCOMP_MODE_FILTER — attaches a BPF program that inspects each syscall and returns an action: SECCOMP_RET_ALLOW, SECCOMP_RET_KILL_PROCESS, SECCOMP_RET_ERRNO, or SECCOMP_RET_TRAP.

Docker Default Profile

Docker ships a default seccomp profile that blocks ~44 dangerous syscalls including ptrace, kexec_load, create_module, and mount. Privileged containers (--privileged) disable seccomp entirely.

Kubernetes Integration

Pod-level: securityContext.seccompProfile.type: RuntimeDefault applies the container runtime's default. Localhost type loads a custom profile from the node's profile directory (/var/lib/kubelet/seccomp/).

Writing a Custom Filter

Use strace -c ./myapp to discover which syscalls your app actually needs before writing an allowlist.

Key concepts

BPF filter: A bytecode program evaluated in-kernel on every syscall. Returns an action (ALLOW/KILL/ERRNO). Cannot be removed once installed by a process without exec.
SCMP_ACT_KILL_PROCESS: Terminates the entire process (not just the thread) when a blocked syscall is attempted. More secure than ERRNO because it prevents the app from recovering.
Docker default profile: Blocks ~44 high-risk syscalls. Applied automatically unless --security-opt seccomp=unconfined or --privileged is set.
RuntimeDefault: Kubernetes seccompProfile type that delegates to the container runtime (containerd/cri-o) default profile.

When to use it

Explaining how Docker reduces container attack surface without full virtualization
Hardening a Kubernetes workload against kernel exploit escalation
Auditing what syscalls a binary needs before writing a restrictive profile

Interview questions

How does Docker use seccomp to reduce container attack surface, and what happens when you use --privileged?
A containerized application crashes with "Operation not permitted" only in production Kubernetes but works in dev Docker. What do you check?