What does a seccomp-BPF filter on Linux actually restrict, and what happens to a process when it makes a system call the filter rejects?

## Where seccomp sits Seccomp is attached to the one chokepoint every process must pass through. Because all interaction with the outside world is a system call, restricting which system calls a process may make is a genuine, complete confinement of what it can do — unlike a restriction applied at a library or language level, which a process can route around by trapping directly. It is worth being precise about what it is not. Seccomp is not a permission system: it does not know about users, files or objects, and it makes no reference to what the process owns. It is a filter on the *interface*. Discretionary permissions, capabilities and mandatory access control all still apply, and seccomp composes with them rather than replacing them. ## The two modes The original strict mode allows only `read()`, `write()`, `_exit()` and `sigreturn()`, killing the process on anything else. It is too narrow for real programs and survives mostly as history. Filter mode is the one in use. The process supplies a classic-BPF program, either through `prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)` or the dedicated `seccomp()` call with `SECCOMP_SET_MODE_FILTER`, which also offers flags such as synchronising the filter across all threads. ## The filter's view of the world The BPF program is evaluated against a fixed input structure the kernel builds at syscall entry, containing: - the system call number, - the audit architecture value identifying the ABI in use, - the instruction pointer of the calling instruction, - the six raw argument register values. The critical limitation follows from that list: **the filter sees register values, not what they point at**. It cannot dereference a pointer argument. It can see that `openat()` was called and what its flags argument was, but it cannot see the pathname, because the string lives in user memory the filter is not allowed to follow — and even if it could, another thread could rewrite the string between the check and the kernel's own copy, a time-of-check-to-time-of-use race. So seccomp is good at "this program may never call `mount()`" and structurally incapable of "this program may only open files under /etc". The architecture field is not decorative. A filter that matches only on syscall numbers, without first checking the architecture, can be bypassed on a kernel that supports a second ABI, because the same number means a different call there. Checking the architecture first and rejecting anything unexpected is the standard opening of every correct filter. ## What happens on rejection The filter's return value carries an action in its high bits and, for some actions, data in the low bits: - `SECCOMP_RET_ALLOW` — proceed to the real handler. - `SECCOMP_RET_ERRNO` — do not run the handler; return failure to the caller with the errno encoded in the return value. The process sees an ordinary failed system call, which is often the kindest option, since a program that gets `EPERM` from an optional call may degrade gracefully rather than die. - `SECCOMP_RET_TRAP` — deliver `SIGSYS` to the calling thread. The handler can inspect the offending call and decide what to do, which is how some sandboxes emulate calls they do not permit natively. - `SECCOMP_RET_KILL_THREAD` — terminate the calling thread as though by `SIGSYS`. - `SECCOMP_RET_KILL_PROCESS` — terminate the whole thread group, which is usually what you want, since killing one thread of a multi-threaded program leaves it in an undefined state. - `SECCOMP_RET_LOG` — allow, but record the call, the mechanism behind building filters observationally before enforcing them. - `SECCOMP_RET_USER_NOTIF` — hand the decision to a supervising process over a file descriptor, which lets a monitor implement policy that BPF cannot express. When several filters are installed, all of them run and the most restrictive result wins; there is no way for a later filter to loosen an earlier one. ## The one-way door and no_new_privs A filter cannot be removed or relaxed once installed. It is inherited by children across `fork()` and preserved across `execve()`. That permanence is what makes it trustworthy: a compromised process cannot lift its own restrictions. It also creates a hazard the kernel closes explicitly. If a filtered process could execute a setuid binary, it could make chosen system calls fail inside privileged code and steer it into unsafe behaviour. So an unprivileged caller must first set the `PR_SET_NO_NEW_PRIVS` bit, which permanently prevents that process and its descendants from gaining privileges through `execve()`. Only a process with `CAP_SYS_ADMIN` may install a filter without it. ## Why filters are fragile in practice Allow-lists break when the C library changes which system call it uses to implement a function — the classic case being older and newer variants of the same operation, where a library upgrade quietly starts issuing a call the filter never permitted. The symptom is a program that worked yesterday dying on an unrelated library update, and it is why observation-then-enforce, generous handling of near-equivalent calls, and preferring an errno return over an immediate kill are all standard practice.