Containers aren’t a security boundary. They package several Linux kernel primitives that happen to produce process isolation as a side effect, and if you treat a container like a VM you’ll eventually get burned. This post covers what enforces container isolation, three escape techniques that have shown up in production, and the mitigations worth bothering with.
What’s actually isolating the container
There’s no single “container” kernel object. Docker, containerd, and friends compose four separate mechanisms.
Namespaces partition what a process can see: pid (process tree), net (network stack), mnt (filesystem mounts), uts (hostname), ipc, and user (UID/GID mapping). A process in a new PID namespace sees itself as PID 1 and can’t see host processes, but it’s still the same kernel, same syscall table, same vulnerabilities.
Cgroups (v1 or v2) limit and account for resource usage: CPU, memory, I/O, PIDs. They control resources, not confidentiality or integrity. Cgroup v1’s release_agent mechanism in particular is a privileged hook that has nothing to do with isolation, and as we’ll see below it can lead straight to host compromise.
Capabilities split root’s power into roughly 40 discrete privileges (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, and so on). A container running as UID 0 with a reduced capability set isn’t the same as host root, but Docker’s default set is still broad, and CAP_SYS_ADMIN alone gets you close to full root for a lot of practical purposes: mount manipulation, cgroup control, some device operations.
Seccomp filters which syscalls a process can invoke at all, independent of capabilities. Docker ships a default profile blocking around 44 syscalls (keyctl, add_key, mount, umount2 in some paths, ptrace variants, kernel module loading, etc). Disabling it with –security-opt seccomp=unconfined is a common way to remove a real security control while chasing a build error you don’t fully understand.
Nobody designed these four mechanisms together as a sandbox. Each closes off a slice of the host kernel’s attack surface, and the escapes live in the gaps between them.
Escape 1: privileged containers and /dev access
docker run –privileged disables almost everything above: full capability set, no seccomp, no AppArmor or SELinux confinement, and access to host devices. If the container can see host block devices under /dev, it can mount the host root filesystem directly:
# inside a --privileged container
mkdir /mnt/hostfs
mount /dev/sda1 /mnt/hostfs
chroot /mnt/hostfs /bin/bash
# now you are root on the host filesystemThis isn’t a bug, it’s documented behavior of –privileged. It still shows up constantly: CI runners, “just make it work” Kubernetes manifests, Docker-in-Docker setups that grab –privileged to avoid debugging a permissions error. The fix is to find the one or two specific capabilities or device mounts the workload actually needs (–cap-add SYS_PTRACE, –device=/dev/foo), which is almost always possible once you check.
Escape 2: CVE-2019-5736, runc file descriptor overwrite
This one is a real runtime race, not a misconfiguration. runc versions before 1.0-rc7 (used under the hood by Docker, containerd, Kubernetes) were vulnerable to an attack where a malicious container could overwrite the host runc binary itself.
Here’s the mechanism: when runc exec enters a running container, it briefly opens its own binary via /proc/self/exe inside the container’s mount namespace, to re-exec itself with dropped privileges. A container process controls its own /proc/self/exe target. Replace your own binary with a malicious ELF that, when run as the container’s entrypoint, opens /proc/self/exe for writing and holds the fd open, and you can race runc into writing to that fd instead of a temp file. Since the host runc binary is mapped in during this handoff, the attacker overwrites the actual runc executable on the host with their own payload. The next container started or exec’d into on that host runs the attacker’s code as root.
It stung because it broke the assumption that “non-privileged container, default config” was safe against a malicious image or a compromised process. The fix was having runc copy itself to a memfd (memfd_create) and exec from there instead of touching a path on disk, which removes the overwritable target. Patch your container runtime (runc, containerd, crun) on the same schedule as your kernel.
Escape 3: cgroup v1 release_agent abuse
Cgroup v1 supports a release_agent file: a host-side executable path the kernel invokes, as root, on the host, whenever a cgroup becomes empty. Give a container CAP_SYS_ADMIN and write access to a cgroup hierarchy’s release_agent, which happens with –privileged or with mounted cgroupfs and relaxed capabilities, and it can point that path at a script of its choosing and trigger it:
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(sed -n 's/.*\perdir:\([^,]*\).*/\1/p' /proc/self/cgroup)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
echo '#!/bin/sh' > /cmd
echo 'ps aux > /output' >> /cmd # runs as host root
chmod +x /cmd
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"Researchers including Felix Wilhelm have written this one up extensively. It works because cgroups were never an isolation mechanism: release_agent is a host-wide control hook, and a sufficiently privileged container process can reach it. Cgroup v2’s unified hierarchy scopes release_agent differently and closes off this specific path, which is one reason to be on v2 by now.
Mitigations that actually reduce risk
Drop capabilities. Start from –cap-drop=ALL and add back only what you’ve actually measured as needed. CAP_SYS_ADMIN, CAP_SYS_PTRACE, and CAP_SYS_MODULE have no business being default-on.
Don’t use –privileged in production. A workload that “needs” it almost always needs one specific capability or device, not the entire host.
Run containers rootless (Podman rootless, or Docker’s rootless mode). User namespace remapping maps “root” inside the container to an unprivileged UID on the host, so a full in-container compromise doesn’t hand over host root.
Keep the runtime patched. CVE-2019-5736-class bugs live in runc, containerd, crun, not in your application code. Track your container runtime’s CVEs with the same priority you give kernel CVEs.
Use seccomp, and don’t disable it just to make an error go away. If a syscall is genuinely blocked and genuinely needed, add it explicitly to a custom profile instead of going unconfined.
Prefer cgroup v2, where the release_agent host-hook vector doesn’t apply the same way.
For genuinely untrusted workloads, reach for a sandboxing runtime. gVisor (runsc) intercepts syscalls in userspace and reimplements the kernel surface; Kata Containers runs each container in a lightweight VM with its own kernel. Both add real isolation boundaries that namespaces and cgroups alone can’t provide, and the performance hit is usually worth it for multi-tenant or untrusted-input workloads.
Every technique above has been public for years, and every mitigation here is a config change. In my experience the gap between “container” and “isolated” is usually a missing –cap-drop, an unpatched runc, or a –privileged flag somebody added to make an error go away. I’d check those first.
