Linux Sandboxing Primitives: Landlock, seccomp-BPF, LSM MAC, Namespaces and Workload Identity

#Start here: the basics in plain words

A program running on Linux can only do things by asking the kernel. It asks through system calls (syscalls): "open this file", "send this packet", "start this process". Everything a sandbox does comes down to answering four questions about those requests:

None of these is "the sandbox". A real sandbox stacks them, and then, for truly untrusted code, adds a wall of a different kind (a user-space kernel like gVisor, or a virtual machine). This page is about the four kernel-level primitives, what each one really stops, where each one leaks, and how a CI runner layers them around a build it does not trust.

                      untrusted build step (shell, Starlark, Go test, npm install)
                                   │ syscalls
            ┌──────────────────────▼──────────────────────────┐
            │ seccomp-BPF   "is this syscall + these numbers allowed?"  │  ← first gate, cheapest
            ├─────────────────────────────────────────────────┤
            │ namespaces    "which files/pids/ifaces does it even see?"  │
            ├─────────────────────────────────────────────────┤
            │ Landlock / AppArmor / SELinux  "may it touch this object?" │  ← LSM hooks, per object
            ├─────────────────────────────────────────────────┤
            │ cgroups v2    "has it used up its CPU/memory/pids?"        │
            └──────────────────────┬──────────────────────────┘
                                   ▼
                          the one shared host kernel  ← every layer above lives inside it

Memory hook

"ask, see, touch, spend"seccomp limits what you can ask, namespaces limit what you can see, MAC limits what you can touch, cgroups limit what you can spend. If an interviewer asks "which primitive would stop X?", map X onto one of those four verbs first.

#Why it matters

Interviewers use this topic to separate people who have run containers from people who understand them. A candidate who says "Docker isolates the process" has not thought about it. A candidate who says "Docker drops to 14 capabilities, installs a seccomp filter that denies about 44 syscalls, loads the docker-default AppArmor profile and puts the process in its own PID, mount, network, IPC and UTS namespaces, but by default not a user namespace, so root inside is root on the host kernel" has.

For an attacker the primitives are the map. A CI job that can run unshare -Ur gets CAP_SYS_ADMIN in a fresh user namespace, and with it reaches kernel code paths (filesystem mounting, network configuration) that ordinary users never touch. Most container escapes of the last five years were not "breaking out of a namespace"; they were kernel bugs reached through a syscall that the sandbox had left open. Which is why the defender's job is to decide, layer by layer, which doors stay open and which bugs that leaves reachable.

#The taxonomy: four kinds of restriction

The primitives are easy to confuse because all four say "no" to a process. They differ in what they inspect and who may set them up.

Three distinctions do most of the work in interviews:

In practiceThe same kernel, three views of one process's restrictions. This is the lab VM (Ubuntu, kernel 6.8, arm64):

$ grep -E "Seccomp|NoNewPrivs|CapEff" /proc/self/status        # an ordinary shell
CapEff:  0000000000000000            ← unprivileged user: no capabilities
NoNewPrivs:  0
Seccomp:  0                          ← no syscall filter at all
Seccomp_filters:  0

$ sudo docker run --rm alpine grep -E "Seccomp|CapEff|CapBnd" /proc/self/status
CapEff:  00000000a80425fb            ← root in the container, but only 14 capabilities
CapBnd:  00000000a80425fb
Seccomp:  2                          ← mode 2 = BPF filter installed by the runtime
Seccomp_filters:  1

$ capsh --decode=00000000a80425fb
cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,
cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
                                     ← no cap_sys_admin, no cap_sys_ptrace, no cap_net_admin

$ sudo docker run --rm --cap-drop ALL --security-opt no-new-privileges alpine grep -E "CapEff|NoNewPrivs" /proc/self/status
CapEff:  0000000000000000            ← what a build step should look like
NoNewPrivs:  1                       ← set-uid binaries can no longer raise privilege

🎯

On the job. /proc/<pid>/status is the first thing to read when someone claims a workload is "sandboxed". Seccomp: 0 on a container means the runtime was started with seccomp=unconfined; CapEff ending in ...ffffffff means --privileged; NoNewPrivs: 0 means a set-uid binary in the image can still escalate. In a Kubernetes pod the same fields tell you whether the securityContext the manifest promised actually reached the process.

#Namespaces and cgroups v2: a smaller world, with a meter

#What a namespace really gives you

A namespace wraps one kind of global kernel resource and gives a process group its own copy of the names. Linux has eight: mount, PID, network, IPC, UTS (hostname), user, cgroup and time. The process still uses the same kernel code for everything; it just cannot name things outside its copy.

#User namespaces: root that isn't root, mostly

The user namespace was designed to make rootless containers possible. The trade-off is sharp. Inside the namespace the process is UID 0 with CAP_SYS_ADMIN, so it can mount filesystems, configure network interfaces and create further namespaces. Those capabilities are "scoped": they only work on objects owned by the namespace. But the kernel code that implements mounting or network configuration is the same code root uses, and now an unprivileged user can reach it.

In practiceCreating a user namespace as an ordinary user on the lab VM:

$ unshare -Ur sh -c 'id; cat /proc/self/uid_map; grep CapEff /proc/self/status'
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)   ← "root"
         0        501          1      ← uid 0 inside == uid 501 outside; only one id is mapped
CapEff:  000001ffffffffff             ← every capability, but only over this namespace's objects

$ unshare -Ur sh -c 'mount -t tmpfs none /mnt'
mount: /mnt: permission denied.       ← CAP_SYS_ADMIN here does not reach the host's mount table

$ unshare -Urm sh -c 'mount -t tmpfs none /mnt && grep /mnt /proc/self/mounts'
none /mnt tmpfs rw,relatime,uid=501,gid=1000,inode64 0 0   ← add a mount namespace and mounting works
$ grep -c /mnt /proc/self/mounts
0                                     ← ...and nobody outside sees it

That last command is exactly what worries kernel maintainers: an unprivileged user just executed the kernel's tmpfs mount path. Ubuntu decided the risk was too high by default:

$ sysctl kernel.apparmor_restrict_unprivileged_userns
kernel.apparmor_restrict_unprivileged_userns = 1       ← Ubuntu 24.04 default (introduced in 23.10)

$ unshare -Ur id
unshare: write failed /proc/self/uid_map: Operation not permitted   ← namespace created, capabilities denied

With the restriction on, a build script can create a user namespace but gets no extra powers inside it unless its AppArmor profile grants userns. Container engines ship such profiles; untrusted build steps do not.

#Why unprivileged user namespaces widen the kernel attack surface

The reason distributions bother to gate this feature is a long run of kernel bugs that were only reachable once an ordinary user could obtain CAP_SYS_ADMIN inside a namespace. CVE-2022-0185 is the standard teaching example: a bounds-check mistake in the kernel's newer filesystem-mounting code could corrupt kernel memory, and the path to triggering it ran through a capability that only root was ever meant to hold. An unprivileged local user could reach it by first unsharing into a new user and mount namespace. The security point is not the individual bug; it is the pattern.

📰

Real incident — CVE-2022-0185 (2022). A heap buffer overflow in the Linux kernel's Filesystem Context code (the fsconfig path added in 5.1) let a local user corrupt kernel memory and escalate to root, and from inside a container it enabled a full host escape. Reaching it required CAP_SYS_ADMIN, which an unprivileged user could obtain by creating a new user namespace. It affected kernels 5.1 through 5.16 and was fixed in early 2022. Lesson: every capability you hand an untrusted workload, even a "namespaced" one, is a licence to run more kernel code; the durable defence is to deny the entry syscalls (unshare, clone with CLONE_NEWUSER) with seccomp rather than trust that the unlocked code is flawless.

#cgroups v2: the meter that stops the noisy neighbour

Namespaces hide things; they do not ration anything. A build that forks endlessly or allocates until the host swaps to death is isolated by namespaces and still takes the machine down. Control groups version 2 (cgroups v2) is the kernel's accounting and limiting layer: every process belongs to one group, and the group has files that cap and meter CPU time, memory, process count and block I/O.

In practiceA container with explicit limits, read from inside it:

$ sudo docker run --rm --memory=256m --cpus=0.5 --pids-limit=64 alpine \
      sh -c 'cat /sys/fs/cgroup/memory.max /sys/fs/cgroup/cpu.max /sys/fs/cgroup/pids.max'
268435456           ← memory.max: 256 MiB, then the OOM killer fires inside this group only
50000 100000        ← cpu.max: 50 ms of CPU per 100 ms window = half a core
64                  ← pids.max: a fork bomb hits 64 and gets EAGAIN, host untouched

When a group hits its CPU ceiling the kernel does not error; it throttles, and that shows up as latency, not failure. The counters make it visible:

$ sudo docker run --rm --cpus=0.5 alpine sh -c 'yes>/dev/null & yes>/dev/null & sleep 3; cat /sys/fs/cgroup/cpu.stat'
nr_periods 31
nr_throttled 31              ← throttled in every single scheduling period
throttled_usec 4552700       ← 4.5 s of wall time spent parked, waiting for quota

🎯

On the job. When a developer says "CI got slow this week and nothing changed", nr_throttled climbing against nr_periods on the runner's cgroup is the smoking gun: the job is CPU-capped and spends its time parked, not working. The fix is more quota or fewer parallel jobs, not more profiling. The same throttled_usec metric is what a multi-tenant platform watches to prove one tenant is not starving another. See the performance-debugging deep dive for reading these under load.

#seccomp-BPF: filtering the request before the kernel reads it

What it isseccomp (secure computing) mode 2 attaches a small BPF program to a thread. For every syscall the thread makes, the program sees the syscall number and the raw register values of the arguments, and returns an action: allow, return an error, trap, notify a supervisor, or kill. It is the cheapest sandbox layer because the check is a tiny program run on a path the kernel already takes.

The one limitation that mattersThe BPF program sees argument registers, which for a pointer means the address, not what it points at. seccomp deliberately cannot dereference a pointer. If it followed the pointer to inspect, say, the path passed to openat(), a second thread could change that memory between the check and the kernel's use of it: a time-of-check-to-time-of-use (TOCTOU) race that would make the filter lie. So seccomp can enforce "never call mount()" or "socket() only with these address families", but it cannot enforce "openat() anything except /etc/shadow". That gap is precisely what Landlock fills.

The privilege ruleInstalling a filter needs either CAP_SYS_ADMIN or the no_new_privs bit already set. The reason is subtle and worth saying out loud in an interview: without it, an unprivileged user could install a filter that makes a set-user-ID helper misbehave (deny a syscall it relies on for a security check) and ride it to root. no_new_privs closes that by promising the kernel this thread can never gain privilege through exec.

Beyond allow/denySECCOMP_RET_USER_NOTIF (Linux 5.0) hands the syscall to a user-space supervisor that decides what to do, so a runtime can emulate a dangerous syscall safely instead of flatly denying it. SECCOMP_FILTER_FLAG_TSYNC applies one filter to every thread in the process at once, so a multithreaded Go runner cannot leave one thread unfiltered. Return actions have a fixed precedence, kill beats trap beats errno beats allow, so when filters stack the most restrictive decision wins.

In practiceDocker's default filter is what stops the user-namespace trick inside an ordinary container:

$ sudo docker run --rm alpine sh -c 'unshare -Ur id; mount -t tmpfs none /mnt'
unshare: unshare(0x10000000): Operation now in progress ... Operation not permitted   ← CLONE_NEWUSER denied by seccomp
mount: permission denied (are you root?)                                               ← mount() denied by seccomp

The container is nominally root with 14 capabilities, yet it cannot create a user namespace or mount anything, because the seccomp filter refuses the syscalls before the capability check is even reached.

📰

Real incident — Dirty Pipe (CVE-2022-0847, 2022). A flaw in the kernel's pipe handling let an unprivileged process overwrite data in files it could only read, including root-owned files, enough to escalate to root on the host and, from a container, to tamper with files in the host's shared page cache. The trigger used ordinary, always-allowed syscalls (splice, write), so no seccomp profile stopped it: the calls themselves are legitimate. Lesson: seccomp shrinks the set of reachable kernel bugs, but a bug in a syscall every program needs is outside its reach. That is the ceiling that pushes untrusted workloads toward gVisor (its own pipe code) or a VM (its own kernel). The sandbox isolation deep dive traces Dirty Pipe through each runtime.

Tip

See it yourselfThe sandbox-isolation lab Level 9a has you write a seccomp profile that blocks one socket family and watch an exploit attempt fail at the first syscall, then Level 5 shows the same program allowed, denied and killed by the three return actions.

#Landlock: unprivileged, object-level sandboxing

What it isLandlock is a Linux Security Module (LSM) that any process, including an unprivileged one, can use to sandbox itself by object: "code running after this point may read under /usr, and nothing else." Because it runs at the LSM hooks inside the kernel, after a path has been resolved to a real file, it can do what seccomp cannot: judge the file, not the syscall number. It first shipped in Linux 5.13 and has grown an ABI version per release since.

The ABI version tells you what a kernel's Landlock can govern, and it grows every release, so a CI job must query it and degrade gracefully rather than assume:

In practiceA real self-sandbox on the lab VM (kernel 6.8 reports Landlock ABI 4). A short program declares every filesystem right as "governed", then grants read-only access under /usr and nothing else, and enforces it on itself:

$ cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,apparmor        ← landlock is active in this kernel

$ python3 landlock_selfbox.py          # create ruleset → PATH_BENEATH read on /usr → no_new_privs → restrict_self
restrict_self -> 0                     ← the sandbox is now live for this process
open /usr/bin/true  OK                 ← allowed: it is under /usr
open /etc/hostname  -> Permission denied   ← denied: outside every granted hierarchy

Note what happened: the process sandboxed itself, with no root, no profile loaded by an administrator, no container runtime. That is Landlock's reason to exist. A build tool, a parser, an image resizer can wrap its own risky stage.

Landlock vs AppArmor/SELinuxAll three are object-level MAC. The split is operational:

🎯

On the job. In a code review, a service that spawns helpers to handle attacker-controlled input (thumbnailing uploads, running a user-supplied linter) is the place to ask "can this helper be wrapped in Landlock and a seccomp filter?" It is a small, unprivileged change that caps the blast radius of a bug in the helper, and unlike an AppArmor profile it ships with the code and needs no fleet-wide rollout.

#Layering: the order the primitives go on

For a CI runner executing a build it does not trust, the layers are applied in a specific order during process startup, because each one constrains the next:

Why that orderno_new_privs must precede seccomp and Landlock or an unprivileged process cannot install them. The namespaces and cgroup must be set up before the filter, because creating them needs syscalls (unshare, mount) that the final seccomp filter will forbid. Get the order wrong and either the setup fails or a gap is left open. This is the sequence a hardened systemd unit encodes declaratively (RestrictNamespaces=, SystemCallFilter=, MemoryMax=), and the sequence a Go runner supervisor runs by hand before exec-ing the build.

📰

Real incident — Leaky Vessels (CVE-2024-21626, 2024). runc, the low-level runtime under Docker, containerd and most of Kubernetes, leaked an open file descriptor pointing at the host filesystem into the container. A malicious image could set its working directory to that descriptor and reach the host root, escaping every namespace. Lesson: namespaces restrict the names a process can use, not the handles it already holds; a leaked file descriptor is a hole no namespace closes. Layering matters because a seccomp or Landlock rule, or simply running the whole thing in a VM, limits what that escaped handle can then do.

#Workload identity: binding credentials to the sandboxed process

A sandbox decides what a job may do to the machine. Workload identity decides what it may prove to others. The two have to be designed together, because the classic CI attack is not a kernel escape at all: it is a malicious dependency in a build step reading the long-lived cloud key sitting in the runner's environment and mailing it out.

The modern pattern removes the standing secret. The runner proves its identity with a short-lived OpenID Connect (OIDC) token the CI platform mints per job, exchanges it for a scoped, minutes-long cloud credential, and that credential is bound to the specific job's claims (repository, ref, environment). There is nothing durable to steal, and a stolen token expires before it is useful.

🎯

On the job. The review smell is any CI pipeline with a cloud access key in its secrets store. Ask "why is this static?" The answer is almost always "we set it up before OIDC federation existed." Replacing it with a per-job token exchange is the single highest-value change you can make to a CI platform's credential posture.

#Network isolation and egress: cutting off exfiltration and metadata theft

The sharpest network risk in CI is the cloud metadata service at 169.254.169.254: a link-local address every instance can reach that hands out the node's own IAM credentials. An untrusted build that reaches it inherits the node role. The network namespace is the primitive that closes it.

Because the job is in its own network namespace with no route to the metadata address, the credential theft fails at the routing layer, before any allowlist decision. This is cheaper and more reliable than trying to filter the one address with firewall rules on a shared interface. The untrusted-workload egress deep dive covers the proxy, DNS-vs-IP allowlisting and DNS-tunnelling defences; the point here is only that the network namespace is the enabling primitive.

🎯

On the job. A quick test of any "isolated" runner: from inside a job, does curl http://169.254.169.254/ connect? If it does, the runner can steal the node's cloud identity, and no amount of secret-scanning fixes that. The durable answer is an empty network namespace plus an egress proxy, not a deny rule bolted onto a shared network.

#When the primitives are not enough

Everything above lives inside the one host kernel. seccomp shrinks the reachable syscalls, Landlock and MAC guard the objects, namespaces hide the world, cgroups meter it, but a bug in a syscall you must allow (Dirty Pipe used splice) is still a bug in the shared kernel. For code you genuinely do not trust, the honest answer in an interview is that defence-in-depth with these primitives raises the cost of an escape but does not remove the shared-kernel assumption. That is the moment to reach for a second kind of wall:

The decision, and the 2026 escape history of each, is the subject of the sandbox isolation deep dive. The primitives on this page are what you use inside whichever wall you pick: even a VM runs its workload under seccomp, dropped capabilities and cgroup limits.