AI
Container Escapes Stem From a Shared Kernel, Not Broken Abstractions
Five container escape CVEs appeared in roughly two years, hitting runc, buildkit, the NVIDIA container toolkit (twice), and Docker Desktop. Each one let a container reach the host file system or execute privileged commands. Moore’s point is not to fault those projects. Her point is that this keeps happening because the container boundary was never a security boundary. It was a mechanism to control resource usage, and the industry started treating it as something it was never designed to be.
From chroot in 1979 to runc in 2016: What the History Tells Us
chroot shipped in Unix in 1979 and only isolated the file system. It did nothing about system calls or network access, and root could bypass it. FreeBSD jails followed in 1999, Solaris containers in 2004, and Linux Containers in 2008, one year after cgroups landed in the kernel. Docker deprecated Linux Containers in 2015 in favor of libcontainer, which was then split into runc and containerd in 2016. That code is still running in production today. Each step layered more kernel features on top of a shared kernel. Nothing changed the shared kernel underneath.
Namespaces and cgroups Only Isolate User Space
Namespaces and cgroups live inside the Linux kernel. Because of where they sit in the stack, they can only isolate resources above them, meaning user space. Anything in the kernel itself can bypass those protections. cgroups can allocate networking resources but cannot enforce security isolation for networking at the kernel level. Confused namespace assignment for file descriptors is one known path that bypasses the isolation namespaces are supposed to provide. This is the structural reason container escapes keep appearing across unrelated projects.
Demo: What an Unprivileged Container Can See on the Host
Moore ran an unprivileged Alpine container and walked through /proc. From inside the container, she read host CPU info, full host memory stats, and kernel modules, including Zen drivers loaded for unrelated work on her dev machine. She then ran tcpdump inside the container and captured ping traffic generated outside the container, on the host. The container had no special privileges. The shared kernel means the host’s network traffic is visible from inside. The kernel uptime counter confirmed the container was new but the kernel had been running for a long time.
Post-Container Technologies and the Return to VMs
The industry is circling back toward virtual machines. sysbox treats each container as a VM using rootless Kubernetes. gVisor adds a user-space system call filter for extra isolation. Kata Containers and Firecracker run containers inside microVMs, giving each workload its own kernel. User namespaces, recently added to Kubernetes itself, let a container run processes as root without granting root on the host. WebAssembly compiles applications to a portable binary instead of packaging them into a container image. Each approach tries to create a real security boundary rather than relying on kernel-level isolation alone.
AI Agent Sandboxing Raises the Stakes for Container Security
Autonomous AI agents run LLM-driven tasks independently, without a human watching. That makes sandboxing them inside containers an active concern. Because agents are non-deterministic, a container escape is harder to anticipate or detect than one from a known application. Moore pointed to published experiments where AI agents were set against each other across container boundaries to probe what a system with no fixed behavior can do to shared kernel resources. Understanding what a container can and cannot isolate becomes more pressing as these workloads become common.
Notable Quotes
this kind of boundary that we’ve made around containers as I’m going to try and convince you of today is not really a security boundary. It’s a mechanism used to control resource usage. Marina Moore · ▶ 03:59
all of these different features we talked about on this previous slide, name spaces, cgroups, etc. are actually features of the Linux kernel that we’re using to kind of create this view of containers. Marina Moore · ▶ 11:29
you can actually see the memory info of the of the the host system. Marina Moore · ▶ 15:06
they’re non-deterministic. Um, and we’ve seen all there’s there’s a couple of really cool um like demos that people have done where they set AI agents against each other to try and like attack other agents in other containers Marina Moore · ▶ 21:54
Key Takeaways
- Namespaces and cgroups isolate user space only; kernel-level code bypasses them.
- Five container escape CVEs across runc, buildkit, NVIDIA, and Docker Desktop prove the boundary fails repeatedly.
- An unprivileged container can read host memory stats, kernel modules, and external network traffic via /proc.
- Modern alternatives (Kata, Firecracker, sysbox) restore VM-style kernel separation to create real security boundaries.
- Non-deterministic AI agents sandboxed in containers make container escape risks significantly harder to manage.
About the Speaker(s)
Marina Moore is a Research Scientist at Edera, which builds a hardened runtime for containers. She maintains TUF (The Update Framework), a CNCF graduated project for secure software update and delivery. She also co-chairs CNCF TAG Security, a technical advisory group that advises projects on security and compliance.