Skip to main content
In this article, we’ll explore how to restrict the system calls (syscalls) that applications can invoke, limiting them to only those essential for their operation. This approach minimizes the attack surface, boosting security by preventing access to all 435+ available Linux syscalls. Even seemingly simple commands, such as using the touch command, trigger multiple syscalls. For example, running:
Running the command again shows similar syscall statistics, illustrating that even everyday applications use numerous syscalls:
Allowing unrestricted syscall access increases the risk of exploitation. For instance, the Dirty COW vulnerability in 2016 exploited the ptrace syscall to write to a read-only file, leading to privilege escalation and container escape.
The image describes CVE-2016-5195, a Linux kernel vulnerability known as "Dirty COW," allowing privilege escalation via a race condition in memory handling.

​
The Role of Seccomp

By default, the Linux kernel permits all user-space programs to invoke any syscall. Seccomp (Secure Computing) is a kernel-level feature, introduced in 2005 and available since Linux version 2.6.12, that allows you to sandbox applications by filtering their allowed syscalls. To verify if your kernel supports Seccomp, run:
If these options are set to “y”, then Seccomp is supported on your system.

​
Demonstrating Seccomp in Action

First, run a container using the popular Docker whalesay image. This container prints Docker’s signature whale ASCII art alongside a provided argument (here, “hello!”):
Next, start another container with an interactive shell. Inside the container, try changing the system time. Note that the shell runs as PID 1:
You can inspect the container’s process status by reading /proc/1/status. The Seccomp field should indicate a value of 2, meaning a filtered Seccomp profile is in use.

​
Seccomp Modes

Seccomp operates in three distinct modes:
  • Mode 0: Seccomp is disabled.
  • Mode 1: Strict mode, permitting only four syscalls: read, write, exit, and sigreturn.
  • Mode 2: Filter mode, allowing a defined subset of syscalls based on a filtering profile. Our container example uses Mode 2.
The diagram below summarizes these modes:
The image outlines three syscall restriction modes: Mode 0 (DISABLED), Mode 1 (STRICT), and Mode 2 (FILTERED).
Docker automatically applies a default Seccomp filter if your host supports Seccomp. This default filter is defined via a JSON document that whitelists approximately 60 syscalls.

​
Default Docker Seccomp Profile

The default Docker profile is designed to block dangerous syscalls such as ptrace, which was exploited in the Dirty COW vulnerability. Here is an example snippet of a default Seccomp JSON profile used by Docker:
The key elements of any Seccomp JSON profile are:
  1. Architectures – Defines the supported CPU architectures (e.g., x86_64, x86, x32).
  2. Syscalls – An array listing syscall names and their permitted actions.
  3. Default Action – Determines how to handle syscalls not explicitly listed. Whitelist profiles typically deny undeclared syscalls.
A whitelist profile explicitly allows certain syscalls while denying all others:
In contrast, a blacklist profile allows all syscalls by default and only denies those specifically listed:
While blacklist profiles are easier to implement, they are inherently less secure compared to whitelist profiles due to the possibility of overlooking dangerous syscalls.
The default Docker Seccomp profile on x86 blocks around 60 syscalls related to functions such as system time adjustments, file system mounts, and kernel module loading. This is why changing the system time in our earlier container failed:
For a complete list of blocked syscalls, refer to the Docker documentation.

​
Custom Seccomp Profiles

Although Docker’s default profile enhances security by restricting many dangerous syscalls, you can further harden your container by using a custom Seccomp profile. For example, to block the mkdir syscall, you might modify the default filter and save it as custom.json:
Start a container using your custom profile with the —security-opt flag:
Within this container, attempting to create a directory using mkdir will result in an error:
It is also possible to disable Seccomp entirely using the “unconfined” flag, though this is strongly discouraged:
Even without a Seccomp profile, certain syscalls (like those used to change the system time) may remain blocked by additional Docker security measures:
Additional security layers are discussed in further lessons.
For more guidance on Docker security and related topics, please refer to the Docker Documentation and other linked resources.

Watch Video