seccomp and AppArmor/SELinux

Capabilities limit what powers a process holds. These controls limit two other things. seccomp limits which syscalls it can make, and the Linux Security Modules — AppArmor on Debian and Ubuntu, SELinux on RHEL and Fedora — limit what files and resources it can touch. They are the layers that contain a process which somehow holds root and capabilities anyway, by blocking the calls and file accesses it would need to do damage.

Docker ships a default seccomp profile that blocks roughly 44 dangerous syscalls out of the 300-plus available, and on most hosts an LSM profile is already confining your containers. Both are on unless you opt out. The skill in this topic is mostly knowing they exist and not turning them off — because the standard wrong move is to disable the whole layer the first time an app trips over it.

seccomp Filters Syscalls

A seccomp profile is an allowlist-or-denylist of system calls — the narrow interface through which every process asks the kernel to do anything. Docker's default profile blocks ~44 calls that a normal container never makes but an escape would: mount, reboot, kexec_load, raw ptrace of other processes, and similar low-level operations. It permits the hundreds of calls an ordinary application actually uses — read, write, open, socket — so the filter is invisible to normal workloads and a wall to abnormal ones.

The Default Profile Is On

Unless you opt out, every container runs under Docker's default seccomp profile. You rarely need to write your own. When you do — for a service you want locked down further, like driftwood/web — you supply a stricter profile with --security-opt seccomp=profile.json. The important thing is that the protection is already there by default; the failure mode is removing it, not forgetting to add it.

# lock driftwood/web down with a stricter profile
docker run -d --name web \
  --user app \
  --cap-drop=ALL \
  --security-opt seccomp=driftwood-web.json \
  -p 8000:8000 \
  driftwood/web

# the wrong move: never do this to get past one blocked syscall
# docker run --security-opt seccomp=unconfined ...

The custom profile driftwood-web.json starts as a copy of Docker's default and removes the few extra syscalls the app demonstrably never makes. The commented-out unconfined line is what you must not reach for: it switches the entire filter off to permit a single call.

AppArmor and SELinux Confine Resources

The LSMs enforce mandatory access control — rules the kernel applies regardless of file permissions or process identity. AppArmor is path-based and default on Debian and Ubuntu through the docker-default profile; SELinux is label-based and default on RHEL and Fedora. Both restrict which files, devices, and capabilities a container can reach even as root, so a confined process cannot read /etc/shadow on the host even if it breaks out of its mount namespace. Where seccomp gates the syscall, the LSM gates the resource the syscall would touch.

Applying Profiles

Both LSMs attach through --security-opt: apparmor=<profile> for AppArmor, label=<option> for SELinux. In practice the defaults are right, and the work is not writing profiles — it is knowing they are there and leaving them on. A custom AppArmor or SELinux profile is occasionally worth it for a tightly scoped service, but the common case is the default profile doing its job silently.

Don't Disable to "Fix" a Bug

The standard wrong move is reaching for --security-opt seccomp=unconfined — or apparmor=unconfined, or label=disable for SELinux — the moment an app hits a blocked syscall or a denied file access. That removes the entire layer to fix one call. It works, the error goes away, and the container now runs with no syscall filter or no mandatory access control at all, which nobody remembers six months later.

The right move is surgical. For a blocked syscall, copy Docker's default seccomp profile and add only the one call the app legitimately needs. For a denied file path, adjust the AppArmor or SELinux policy to allow that path. You keep the layer and open exactly the one hole the workload requires, rather than tearing the wall down because one brick was in the way.