zlacker

[parent] [thread] 5 comments
1. easter+(OP)[view] [source] 2025-12-18 00:38:07
If the container is running in privileged mode you can just talk to the docker socket to the daemon on the host, spawn a new container with direct access to the root filesystem, and then change anything you want as root.
replies(1): >>CGames+Vh
2. CGames+Vh[view] [source] 2025-12-18 03:40:44
>>easter+(OP)
Notably, if you run docker-in-docker, Docker is probably not a security boundary. Try this inside any dind container (especially devcontainers): docker run -it --rm --pid=host --privileged -v /:/mnt alpine sh

I disagree with other commenters here that Docker is not a security boundary. It's a fine one, as long as you don't disable the boundary, which is as easy as running a container with `--privileged`. I wrote about secure alternatives for devcontainers here: https://cgamesplay.com/recipes/devcontainers/#docker-in-devc...

replies(1): >>flamin+Ev
◧◩
3. flamin+Ev[view] [source] [discussion] 2025-12-18 06:36:10
>>CGames+Vh
Containers are never a security boundary. If you configure them correctly, avoid all the footguns, and pray that there's no container escape vulnerabilities that affect "correctly" configured containers then they can be a crude approximation of a security boundary that may be enough for your use case, but they aren't a suitable substitute for hardware backed virtualization.

The only serious company that I'm aware of which doesn't understand that is Microsoft, and the reason I know that is because they've been embarrassed again and again by vulnerabilities that only exist because they run multitenant systems with only containers for isolation

replies(1): >>vel0ci+Cz1
◧◩◪
4. vel0ci+Cz1[view] [source] [discussion] 2025-12-18 15:19:52
>>flamin+Ev
Virtual machines are never a security boundary. If you configure them correctly, avoid all the footguns, and pray that there's no VM escape vulnerabilities that affect "correctly" configured VMs then they can be a crude approximation of a security boundary that may be enough for your use case, but they aren't a suitable substitute for entirely separate hardware.

Its all turtles, all the way down.

replies(1): >>flamin+4F1
◧◩◪◨
5. flamin+4F1[view] [source] [discussion] 2025-12-18 15:37:57
>>vel0ci+Cz1
Yeah, in some (rare) situations physical isolation is a more appropriate level of security. Or if you want to land somewhere in between, you can use VM's with single tenant NUMA nodes.

But for a typical case, VM's are the bare minimum to say you have a _secure_ isolation boundary because the attack surface is way smaller.

replies(1): >>vel0ci+II1
◧◩◪◨⬒
6. vel0ci+II1[view] [source] [discussion] 2025-12-18 15:51:09
>>flamin+4F1
Yeah, so secure.

https://support.broadcom.com/web/ecx/support-content-notific...

https://nvd.nist.gov/vuln/detail/CVE-2019-5183

https://nvd.nist.gov/vuln/detail/CVE-2018-12130

https://nvd.nist.gov/vuln/detail/CVE-2018-2698

https://nvd.nist.gov/vuln/detail/CVE-2017-4936

In the end you need to configure it properly and pray there's no escape vulnerabilities. The same standard you applied to containers to say they're definitely never a security boundary. Seems like you're drawing some pretty arbitrary lines here.

[go to top]