The builder behind Codeandcake decided to write a container runtime for fun and came away with a blunt verdict. Docker is weird. I think the weirdness is useful because it exposes the security boundary exactly where it is.
What was demoed is local isolation on Linux, not a remote exploit. Containers are still host processes you can find in /proc, according to the post. An attacker already needs local execution. The affected system is any Linux host running containers, and the privilege question is the point.
There is no single container feature in Linux. The post describes containers as five kernel features in a trenchcoat. Namespaces hide what host and container can see. Cgroups limit resource usage. Networking magic isolates the container network. Images add one more sleight of hand. They are just folders Docker puts somewhere, then the runtime calls chroot or pivot_root to make that folder the new root. Run docker run -it --rm ubuntu /bin/bash and Docker downloads the ubuntu image from Docker Hub, drops it on disk, then executes /some/weird/docker/path/bin/bash under that new root.
That model shapes the tooling. Docker's runtime, runc, is written in Go. Go is natively multi-threaded, which is good for services and awkward for a runtime that must make syscalls in a single-threaded context. Per the post, runc carries a C module that runs before Go's runtime initializes to handle those calls. Go also has no fork. Fork only clones the main thread, so runc approximates fork by re-execing /proc/self/exe with a special argument that marks the child, then setting up restrictions before execing the target command.
Root is the last surprise. Many kernel APIs container runtimes rely on require root, so the Docker daemon usually runs as root. The author notes this is easy to miss on macOS. Rootless is better now, the post says, with one big exception. Networking. A rootless runtime has to reimplement much of the networking stack in userspace to give the same features. That is a concession worth stating plainly. Rootless reduces host risk, but shifts complexity and attack surface into userspace networking.
Against the standard framing this reads differently. AWS describes Docker as a platform that allows you to build, test, and deploy applications quickly using containers, and AWS separates Docker images as templates from containers as runnable instances. Codeandcake collapses that distinction. Images are folders. Containers are processes with restrictions. If you are choosing defaults for a startup, assume containers are local processes and design permissions, seccomp, and network policy from that premise.
