iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Seccomp is a Linux kernel feature that limits which system calls a process can make. A process can install a filter that checks syscall details and tells the kernel to allow, reject, log, trap, or terminate a call. It narrows the kernel interface an application can reach, but it does not create a complete sandbox on its own.
What does seccomp restrict?
Linux system calls are the main interface applications use to request services from the kernel, such as opening files, creating processes, or communicating over sockets. A seccomp filter evaluates a syscall as it is requested and can base its decision on the syscall number, syscall architecture, instruction pointer, and argument register values. It does not inspect arbitrary application data by following pointer arguments into memory.
That boundary matters: seccomp can restrict which kernel operations a process may request, but it is not a general policy language for examining file contents or other data addressed by pointers. The Linux kernel documentation warns that filtering by syscall number without checking the architecture can be unsafe, because syscall conventions and number assignments can differ. Linux kernel documentation: Seccomp BPF
Free tools Windows power users keep installed
One-click scans. No signup required.
How does a process install a seccomp filter?
In filter mode, a process installs a small BPF program using either prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, ...) or the seccomp() system call. Installation requires the process to have set no_new_privs or to have CAP_SYS_ADMIN in its user namespace. The requirement helps prevent a process from gaining privilege by installing a filter and then executing a program with greater privileges. Linux kernel documentation: Seccomp BPF
#1 Best Overall
Eligible child processes inherit installed filters. A process can also add more filters if its existing restrictions permit it; stacked filters can narrow the available behavior further. A filter therefore has to account for the process lifecycle: for example, whether it must continue to fork or execute other programs.
What can a seccomp filter do with a syscall?
Seccomp supports more than a simple allow-or-deny outcome. A filter selects an action, and the kernel applies action precedence when multiple filters are stacked.
Rank #2
| Action | Effect |
|---|---|
SECCOMP_RET_ALLOW |
Allows the syscall to proceed. |
SECCOMP_RET_ERRNO |
Rejects the syscall and returns an error number to the caller. |
SECCOMP_RET_TRAP |
Raises SIGSYS for the calling process to handle or for the default signal behavior to apply. |
| Kill actions | Terminate the calling thread or process, depending on the action. |
SECCOMP_RET_LOG |
Allows the syscall while requesting that it be logged, subject to kernel logging behavior. |
SECCOMP_RET_TRACE |
Notifies a ptrace tracer so it can participate in handling the syscall. |
SECCOMP_RET_USER_NOTIF |
Sends a notification to a userspace listener for handling. |
These outcomes are documented in the Linux kernel seccomp filter reference. A notification listener is an advanced mechanism, not a general-purpose way to implement security policy. The Linux man-pages caution that notification handling has subtleties, including interruption and safely reading data from a tracee’s memory. Linux man-pages: seccomp_unotify(2)
Is seccomp a sandbox?
No. Linux kernel documentation states that “System call filtering isn’t a sandbox.” Seccomp reduces the kernel surface exposed to an application; by itself, it does not define filesystem access, network policy, information flow, or all application behavior. Use it as one layer alongside controls suited to the threat model, such as namespaces, Linux capabilities, and a Linux Security Module (LSM) policy. Linux kernel documentation: Seccomp BPF
Filters also have important technical limits. They inspect argument register values but cannot dereference pointer arguments, and a call that is handled by the vDSO in userspace on one system may fall back to a kernel syscall on another. That can make behavior differ across systems or tests. The kernel documentation advises checking the syscall architecture as well as its number.
What do Docker and Kubernetes seccomp profiles mean?
Docker: the runtime’s default profile or a custom JSON profile
Docker documents that containers use its default seccomp profile unless it is overridden. The profile is an allowlist: calls are denied by default unless explicitly permitted. Docker’s current documentation describes the default as disabling around 44 system calls out of more than 300; this is Docker’s profile characterization, not a universal Linux constant, and can change with Docker releases. Docker Docs: Seccomp security profiles for Docker
An operator can provide a custom JSON profile with --security-opt seccomp=.... Docker recommends retaining the default profile in ordinary cases. Its documented rules include argument-specific conditions, and its notes discuss compatibility details involving AF_ALG, AF_VSOCK, and 32-bit socketcall behavior. The actual effect depends on the Docker release, kernel, architecture, and other active security policies.
Recommended Free Tools
Kubernetes: RuntimeDefault, Localhost, or Unconfined
Kubernetes lets an operator select a seccomp profile for a Pod or individual container. The three documented profile types differ in who supplies the rules and whether restrictions apply:
| Profile type | What it selects | Operational consideration |
|---|---|---|
RuntimeDefault |
The container runtime’s default seccomp profile. | Rules can differ by runtime, runtime version, architecture, and kernel support. |
Localhost |
A profile installed and managed on the node. | The profile must be distributed and maintained across nodes. |
Unconfined |
No seccomp restrictions from a profile. | A privileged container runs unconfined. |
The behavior of RuntimeDefault depends on the installed runtime; Kubernetes notes that runtimes such as CRI-O and containerd may have different defaults. Kubernetes’ seccompDefault kubelet setting became stable in v1.27. When an operator enables it on a node, workloads without an explicit profile use RuntimeDefault; it is not automatically enabled for every cluster. Kubernetes: Seccomp and Kubernetes
How should operators choose and maintain a profile?
For many workloads, starting with the runtime default is a practical balance: it provides syscall filtering without requiring an operator to maintain a bespoke policy for every application. A custom profile can restrict a workload further, but tight allowlists may break when software changes its syscall needs. Kubernetes also cautions that custom profiles can still leave allowed syscalls exploitable and can become difficult to manage across many workloads. Kubernetes: Linux kernel security constraints for Pods and containers
- Confirm which runtime, runtime version, kernel, and architecture are actually in use; do not assume a profile has identical rules everywhere.
- Exercise normal and less-common application paths with the intended profile before deploying it broadly.
- Re-test after application, kernel, or runtime updates, since software may start using different system calls.
- Use local profiles only when you can distribute and maintain the same intended policy on every relevant node.
- Treat seccomp as one control among several, rather than relying on it to define filesystem, network, or broader application access.
Kubernetes recommends testing profiles and workloads before rollout, particularly when enabling node-level defaulting or deploying custom policies. Kubernetes: Linux kernel security constraints for Pods and containers
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
