Tag: containers

Containers aren’t a security boundary. They’re a convenient packaging of several Linux kernel primitives that happen to produce process isolation as a side effect. Treat a container like a VM and you’ll get burned eventually. This post covers what actually enforces container isolation, two 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 everything to do with host compromise, as we’ll see below.

Capabilities split root’s omnipotence 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 one of the most common ways people remove a real security control while chasing a build error they don’t fully understand.

None of these four mechanisms were designed together as a sandbox. Each one 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 filesystem

This isn’t a bug. It’s documented behavior of –privileged. But it shows up constantly anyway: CI runners, “just make it work” Kubernetes manifests, Docker-in-Docker setups that grab –privileged to avoid debugging a permissions error. The fix is never “use –privileged.” It’s finding 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 bother to check.

Escape 2: CVE-2019-5736, runc file descriptor overwrite

This one’s a genuine kernel/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.

What makes this one sting is that 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 kills the overwritable target entirely. Patch your container runtime, runc, containerd, crun, on the same schedule as your kernel. Don’t treat it as an afterthought.

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, and it works for a simple reason: cgroups were never an isolation mechanism. release_agent is a host-wide control hook, and a sufficiently privileged container process can just reach out and grab it. Cgroup v2’s unified hierarchy scopes release_agent differently and closes off this specific path, one of several reasons to be on v2 by now.

Mitigations that actually reduce risk

Drop capabilities aggressively. 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, period. 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, not a research project. In my experience the gap between “container” and “isolated” is almost always one of three things: a missing –cap-drop, an unpatched runc, or a –privileged flag somebody added to make an error go away. Check those three first.