2 ms·
Last I checked, Docker wasn't considered a security boundary and Docker escapes weren't considered a security issue. The most obvious escapes have slowly been m
by px43 3y ago
Last I checked, Docker wasn't considered a security boundary and Docker escapes weren't considered a security issue. The most obvious escapes have slowly been mitigated over time, but the prevailing wisdom is that you should always assume that an attacker can work their way from the container to the host system. Obviously never put anything sensitive on a docker host, and assume anything running on the host (like the other docker containers) is running at the same privilege level.
- nyrikki 3y agoI tried for a long time to even get docker to just give a config option to disable privileged mode with no success. I even resorted to posting instructions on stack exchange demonstrating how to walk /sys to find device numbers and use mknod to read the hosts root volume and now as most servers don't mount their efi partition, how you could mount it rw inside a container with little effort. Containers are namespaces and purely depend on privilege dropping for the security they provide. Part of the problem is that container breakout is narrowly defined. The fact that a privileged container can upload firmware or access private keys by reading the hosts root volume didn't count. While the ability to disable privileged mode wouldn't have solved this issue it still would have reduced the attack surface. But will the projects refusal to even take that step I gave up. Deciding that the only safe option was to consider containers as namespaces and nothing more. Unfortunately adding persistence and other functionality tends to result people running it as uid0, which means that you have to consider as anything that can launch a container as having superuser privileges.