[Scramblejams]

Apologies for repeating myself all over this part of the thread, but the vulnerabilities here are something that Podman and Docker can't really do anything about as long as they're sharing a kernel between containers.

The vulnerability is in kernel syscalls. More info here: https://news.ycombinator.com/item?id=32319067

If you're going to make containers hard to escape, you have to host them under a hypervisor that keeps them apart. Firecracker was invented for this. If Docker could be made unescapable on its own, AWS wouldn't need to run their container workloads under Firecracker.

[Anonbrit]

This same, not especially informative content is being linked to again and again in this thread. If container escapes are so common, why has nobody linked to any of them rather than a comment saying "There are lots" from 3 years ago?

[Scramblejams]

I did apologize, didn't I? :-)

Perspective is everything, I guess. You look at that three year old comment and think it's not particularly informative. I look at that comment and see an experienced infosec pro at Fly.io, who runs billions of container workloads and doesn't trust the cgroups+namespaces security boundary enough so goes to the trouble of running Firecracker instead. (There are other reasons they landed there, but the security angle's part of it.)

Anyway if you want some links, here are a few. If you want more, I'm sure you can find 'em.

CVE-2022-0492: https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups

CVE-2022-0847: https://www.datadoghq.com/blog/engineering/dirty-pipe-contai...

CVE-2023-2640: https://www.crowdstrike.com/en-us/blog/crowdstrike-discovers...

CVE-2024-21626: https://nvd.nist.gov/vuln/detail/cve-2024-21626

Some are covered off by good container deployment hygiene and reducing privilege, but from my POV it looks like the container devs are plugging their fingers in a barrel that keeps springing new leaks.

(To be fair, modern Docker's a lot better than it used to be. If you run your container unprivileged and don't give it extra capabilities and don't change syscall filters or MAC policies, you've closed off quite a bit of the attack surface, though far from all of it.)

But keep in mind that shared-kernel containers are only as secure as the kernel, and today's secure kernel syscall can turn insecure tomorrow as the kernel evolves. There are other solutions to that (look into gVisor and ask yourself why Google went to the trouble to make it -- and the answer is not "because Docker's security mechanisms are good enough"), but if you want peace of mind I believe it's better to sidestep the whole issue by using a hypervisor that's smaller and much more auditable than a whole Linux kernel shared across many containers.