Linux Capabilities & Seccomp Hardening

Learning outcomes

• Restrict root process privileges using Linux capabilities
• Build restrictive seccomp BPF filters for production containers

Mental model

Traditional Linux security treats root (UID 0) as an all-powerful superuser. POSIX Capabilities partition root privileges into fine-grained permissions. Seccomp (Secure Computing Mode) acts as a kernel firewall for system calls, intercepting and blocking dangerous syscalls before execution.

Theory

• POSIX Capabilities:
  • CAP_NET_ADMIN: Perform network configuration tasks.
  • CAP_SYS_ADMIN: Overly permissive legacy root capability (mount, cgroups, eBPF).
  • CAP_NET_BIND_SERVICE: Bind sockets to privileged ports (< 1024).
• Seccomp BPF: Uses BPF filters attached to prctl(PR_SET_SECCOMP) to audit system call numbers and arguments. Default Docker/Kubernetes seccomp profiles block ~40 dangerous syscalls (e.g. reboot, kexec_load, ptrace).

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "exit", "sigreturn", "epoll_wait", "futex"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

# Drop all capabilities in Docker container and add back only NET_BIND_SERVICE
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE --security-opt seccomp=default_profile.json my_app:latest

Alternatives and trade-offs

• Running Unrestricted Container Root: High security risk; a container breakout compromises the host kernel.
• Capabilities Drop + Seccomp BPF: Strict principle of least privilege; restricts process execution capability even if an attacker gains root code execution.

Failure modes and misconceptions

1. Granting --privileged Flag in Docker: Passing --privileged disables all seccomp filters, grants ALL capabilities, and disables AppArmor/SELinux protection, completely invalidating container isolation boundaries.
2. Blocking Required Syscalls: Overly restrictive custom seccomp profiles blocking syscalls like epoll_create or futex cause applications to crash instantly with SIGSYS or EPERM errors on startup.

Decision scenario

Enforce --cap-drop=ALL and attach restrictive Seccomp BPF profiles to all containerized workloads to enforce the principle of least privilege in production.

Learning outcomes

• Drop unneeded root capabilities using POSIX Capabilities.
• Build custom Seccomp BPF profiles to block dangerous system calls.
• Prevent container breakout vulnerabilities by eliminating --privileged flags.

Trade-offs

Capabilities and Seccomp provide robust process sandbox hardening, but require auditing application system call dependencies to avoid blocking required syscalls.

Primary sources

• Linux Kernel Kernel.org Official Architecture & Systems Documentation — Linux Kernel Organization, verified 2026-07-23