Hacker News Reader

Comment by Hugsun | Hacker News Reader

Docker containers use Linux kernel features to create an isolated environment, running on the same machine as docker is. This creates a virtual machine, with its own kernel, and runs the container in there. This gives stronger isolation and security guarantees.

View on HN

I have the same question as GP. Your answer helps a little but not really. I might be naive, but I was under the impression that malicious code escaping a docker image and running amok on my host system was not something I should be too worried about. Especially if I run docker in rootless mode. Is that wrong?

For clarity I’m actually using podman, not Docker.

Oh no, you should definitely be worried about that. Podman might make it harder to escalate to host root, or manipulate other containers, but it is still vulnerable.

Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.

Unsettling. I mean, is there any reasonable way to develop software in 2026? I've already sworn off ever installing npm directly on my host. Containerizing everything is laborious enough, but running a separate VM for everything?

You just need to work out the threat model for what you're working on. For trusted containerized workloads, where the attack surface is minimal, just containerization is fine. However, agents can do just about anything on your computer if you allow it and people aren't really shying away from `--dangerously-skip-permissions`, so better hardening (VMs, microVMs) is desirable.

BS.

Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.

So yeah, not "vulnerable".

LLMs are great at finding 0-day, and people are rubbish at updating their containers and hosts to patch b-day.

Containers have access to the kernel ABI, and as shown in the latest kernel exploits, all the memory handling surface that exposes. The virtualisation interface, offering fewer services, is significantly harder.

Containers are obviously lighter than VMs, both to start and to schedule, but firecracker is pretty fast. gVisor pays overhead per syscall vs at startup.

So yeah, more vulnerable.

Got it. 0 days are possible so throwaway containerization. You should blog about it, will help millions of developers and companies. Heck, even consult with the hyperscalers - they will be riddled with their workloads.

Who do you think created firecracker? gVisor?

gvisor's overhead is mostly IO. especially if you use the KVM backend.

That depends on the runtime though. For example, libkrun lets you do this:

    docker run --runtime krun hello-world

That starts/runs the OCI in a qemu microvm.

When the host is a Mac or window , docker always run in a VM anyway.

On Linux, you can run docker directly on the host, but you can also very easily setup a vm with incus and run docker from there.

Reply on news.ycombinator.com