seccomp
/ SEK-komp /
Even if a program is fully compromised and the attacker is running arbitrary code inside it, that code can only harm the wider system by asking the kernel to do things — open files, start processes, talk to the network — and it asks via system calls. seccomp is a Linux mechanism that lets a program tell the kernel, in advance, exactly which system calls it is allowed to make, so any call outside that list is blocked. It shrinks the damage a hijacked process can do.
It works as a kernel-enforced filter on the syscall interface. The richer mode, seccomp-bpf, lets a process install a small BPF program — a tiny decision routine the kernel runs on EVERY system call the process attempts. The filter inspects the syscall number (and, with care, some argument values) and returns a verdict: allow it, deny it with an error like EPERM, kill the process, or trap to a handler. A program installs this filter early, while it is still trusted, and the kernel enforces it from then on irreversibly — the process cannot loosen its own filter later. So a media decoder might allow only read(), write(), exit(), and a handful of memory calls, and forbid execve(), socket(), and open(); if exploited, the attacker's shellcode that tries to execve("/bin/sh") is killed by the kernel before it runs.
It matters as a core sandboxing primitive: browsers put each renderer in a tight seccomp sandbox, and container runtimes apply a default seccomp profile to every container. It embodies least privilege at the kernel boundary — give the code only the syscalls it truly needs. The honest caveats: writing a correct filter is hard, because a program (and its libc) may use more syscalls than you expect, and an overly tight filter crashes legitimate work; filtering on ARGUMENTS is limited because the kernel sees only the register values, not memory the pointers reference (so it cannot, by itself, safely inspect a path string and avoid time-of-check/time-of-use races). seccomp reduces the attack surface; it does not make a compromised process harmless.
// conceptual seccomp-bpf policy installed while still trusted: allow: read, write, exit_group, mmap, munmap deny: execve, socket, open, ptrace // -> EPERM or SIGKILL // later: attacker shellcode calls execve("/bin/sh") -> killed by the kernel
The filter is installed early and is irreversible; every later syscall is checked against the allow/deny verdict.
seccomp filters on syscall numbers and register-level arguments, not on memory the pointers reference, so it cannot by itself vet a path string safely; and a too-tight profile breaks legitimate code, since libc uses more syscalls than you think.