zlacker

While this is true, the general security stance on this is: Docker is not a security boundary. You should not treat it like one. It will only give you _process level_ isolation. If you want something with better security guarantees, you can use a full VM (KVM/QEMU), something like gVisor[1] to limit the attack surface of a containerized process, or something like Firecracker[2] which is designed for multi-tenancy.

The core of the problem here is that process isolation doesn't save you from whole classes of attack vectors or misconfigurations that open you up to nasty surprises. Docker is great, just don't think of it as a sandbox to run untrusted code.

1. https://gvisor.dev/

2. https://firecracker-microvm.github.io/

>>d4mi3n+(OP)
that's a really good point .. but, I think 99% of docker users believe it is a a sandbox and treat it as such.

>>d4mi3n+(OP)
Virtual machines are treated as a security boundary despite the fact that with enough R&D they are not. Hosting minecraft servers in virtual machines is fine, but not a great idea if they’re cohosted on a machine that has billions of dollars in crypto or military secrets.

Docker is pretty much the same but supposedly more flimsy.

Both have non-obvious configuration weaknesses that can lead to escapes.

>>socalg+p6
And not without cause. We've been pitching docker as a security improvement for well over a decade now. And it is a security improvement, just not as much as many evangelists implied.

>>socalg+p6
it is a sandbox against unintentional attacks and mistakes (sudo rm -rf /)

but will not stop serious malware

>>freedo+q9
Must depend on who you've been talking to. Docker's not been pitched for security in the circles I run in, ever.

>>hsbaua+k9
Yeah but why would somebody co-host military secrets or billions of dollars? Its a bit of a stretch

>>hoppp+ce
I think you’re missing the point, which was that high value targets adjacent to soft targets make escapes a legitimate target, but in low value scenarios vm escapes aren’t worth the R&D

>>socalg+p6
Not 99%. Many people run an hypervisor and then a VM just for Docker.

Attacker now needs a Docker exploit and then a VM exploit before getting to the hypervisor (and, no, pwning the VM ain't the same as pwning the hypervisor).

>>Tactic+qp
'Double-bagging it' was what we called it in my day.

>>Tactic+qp
Agreed - this is actually pretty common in the Proxmox realm of hosters. I segment container nodes using LXC, and in some specific cases I'll use a VM.

Not only does it allow me to partition the host for workloads but I also get security boundaries as well. While it may be a slight performance hit the segmentation also makes more logical sense in the way I view the workloads. Finally, it's trivial to template and script, so it's very low maintenance and allows for me to kill an LXC and just reprovision it if I need to make any significant changes. And I never need to migrate any data in this model (or very rarely).

>>hsbaua+Ke
but if you can do it at scale it might still be worth it, like owning thousands of machines

>>d4mi3n+(OP)
I hear the "Docker is not a security boundary." mantra all the time, and IIRC it was the official stance of the Docker project a long time ago, but is this really true?

Of course if you have a kernel exploit you'd be able to break out (this is what gvisor mitigates to some extent), nothing seems to really protect against rowhammer/memory timing style attacks (but they don't seem to be commonly used). Beyond this, the main misconfigurations seem to be too wide volume bindings (e.g. something that allows access to the docker control socket from inside the container, or an obviously stupid mount like mounting your root inside the container).

Am I missing something?

>>hsbaua+k9
> Virtual machines are treated as a security boundary despite the fact that with enough R&D they are not. Hosting minecraft servers in virtual machines is fine, but not a great idea if they’re cohosted on a machine that has billions of dollars in crypto or military secrets.

While I generally agree with the technical argument, I fail to see the threat model here. Is it that some external threat would have prior knowledge that an important target is in close proximity to a less hardened one? It doesn't seem viable to me for nation states to spend the expensive R&D to compromise hobbyist-adjacent services in a hope that they can discover more valuable data on the host hypervisor.

Once such expensive malware is deployed, there's a huge risk that all the R&D money is spent on potentially just reconnaissance.

>>kevinr+yq2
Yes. Docker too.