{"title":"Tianon's Ramblings \u273f","link":[{"@attributes":{"href":"https:\/\/ram.tianon.xyz\/"}},{"@attributes":{"type":"application\/atom+xml","rel":"self","href":"https:\/\/ram.tianon.xyz\/atom.xml"}}],"updated":"2026-05-20T19:42:39-07:00","id":"https:\/\/ram.tianon.xyz","author":{"name":"Tianon Gravi","email":"admwiggin@gmail.com","uri":"https:\/\/ram.tianon.xyz"},"entry":[{"id":"https:\/\/ram.tianon.xyz\/post\/2026\/05\/20\/container-security","link":{"@attributes":{"type":"text\/html","rel":"alternate","href":"https:\/\/ram.tianon.xyz\/post\/2026\/05\/20\/container-security.html"}},"title":"Containers Are a Security Boundary (some assembly required)","published":"2026-05-20T00:00:00-07:00","updated":"2026-05-20T00:00:00-07:00","author":{"name":"Tianon Gravi","email":"admwiggin@gmail.com","uri":"https:\/\/ram.tianon.xyz"},"content":"

I've heard \"containers are not a security boundary\" enough times that it's started to feel like received wisdom, and my honest read (after 13+ years) is that it's technically<\/em> defensible but practically sloppy \u2013 and the sloppiness matters.<\/p>\n\n

The part that's true: containers share a kernel, and a kernel exploit crosses the container boundary where a VM would not. That difference is real and non-trivial, and the CVE history backs it up \u2013 CVE-2019-5736, CVE-2022-0492, and CVE-2024-21626 all happened in \"correctly configured\" production containers.<\/p>\n\n

The part I'd push back on is that the comparison point is almost never stated. \"Containers aren't a security boundary\" is being used as shorthand for \"containers aren't a VM boundary\" \u2013 but the conclusion people seem to draw from that is \"therefore don't bother\", which doesn't actually follow. The more honest version is that default<\/em> Docker doesn't provide strong isolation between mutually untrusting parties, but a hardened configuration does.<\/p>\n\n

What ships by default in Moby is actually a pretty reasonable foundation: seccomp is enabled (with a builtin profile blocking ~50 syscalls \u2013 credit where it's due: this is mostly @jessfraz<\/a>'s work; she even ran contained.af<\/a> as a public CTF for years daring people to escape a container under her seccomp profile, and to my knowledge it was never claimed), AppArmor is enabled (the docker-default<\/code> profile), and several sensitive \/proc<\/code> paths are masked. What's not<\/em> on by default: no-new-privileges<\/code> (setuid binaries inside can escalate), CAP_NET_RAW<\/code> is still granted to every container (even though the kernel has supported unprivileged ICMP sockets for over a decade, meaning most modern distributions no longer need CAP_NET_RAW<\/code> for ping<\/code>), and user namespace remapping \u2013 though user namespaces aren't quite the silver bullet they might sound like; Debian left them disabled by default for years<\/a> because the kernel attack surface they exposed hadn't been hardened against unprivileged callers.<\/p>\n\n

The boundary isn't absent \u2013 it doesn't come completely pre-assembled. With VMs, the hypervisor is there whether you asked for it or not; with containers, assembling the boundary is left as an exercise for the operator. That's a much more solvable problem than \"the technology is incapable\", but it does mean the work falls to whoever's running the containers.<\/p>\n\n

So, some things you can do today without waiting for defaults to change:<\/p>\n\n

--user<\/code> (or USER<\/code> in your Dockerfile)<\/strong> is worth calling out specifically, because I think it's arguably stronger<\/em> than user namespace remapping in one important way \u2013 and partly for the same reason Debian was hesitant about user namespaces in the first place. User namespace remapping protects the host from a root-in-container escape: if you do escape, you land as an unprivileged user on the host. But you were still root inside the container the whole time. Running as a non-root user means you were never root anywhere. The blast radius of a compromised process is limited whether or not it escapes, including for things like reading secrets, modifying container contents, or lateral movement within the container itself. Most application containers have no legitimate reason to be root.<\/p>\n\n

Beyond that, a short list of things that are easy to enable and hard to justify leaving off:<\/p>\n\n