System Call Filtering with Seccomp

System Call Filtering with Seccomp

In this lesson, you will learn how to reduce the kernel attack surface of containerized applications by restricting the system calls they are permitted to execute via Seccomp.

The Problem: The Kernel Interface

A containerized process relies on the Linux kernel to perform privileged operations like opening files, creating network sockets, or managing processes. While namespaces provide an isolated view of the system, they do not prevent a process from interacting with the kernel itself. If a containerized application is compromised, an attacker can use these system calls to exploit kernel vulnerabilities, perform privilege escalation, or break out of the container boundary.

The Solution: Secure Computing Mode (Seccomp)

Seccomp (Secure Computing) is a kernel feature that acts as a gatekeeper. By applying a Seccomp profile to a process, you create a "deny-list" or "allow-list" of system calls. If an application attempts to invoke a restricted system call, the kernel can take actions ranging from logging the attempt to immediately terminating the process (SIGKILL).

For example, most web applications have no legitimate reason to execute reboot or mount. By filtering these out, you drastically narrow the potential damage an attacker can inflict.

Applying Seccomp in Containers

When you run a container, the container engine (like Docker or CRI-O) applies a default Seccomp profile that blocks dangerous calls while remaining compatible with common applications. You can define custom profiles using JSON files to restrict specific syscalls further.

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

In the snippet above, the policy defaults to returning an error (EPERM) for all syscalls except for the explicit allow-list. This "Default Deny" posture is the gold standard for hardening containerized workloads, ensuring that even if an attacker gains shell access, their ability to interface with the underlying host kernel is heavily constrained.

Key Takeaway: Seccomp enforces the principle of least privilege at the kernel interface level by explicitly blocking unnecessary system calls, effectively minimizing the impact of a compromised container process.