| 99% of this is inapplicable to this discussion because it's about misconfigurations. Escapes: - privileged mode (misconfiguration, not default or common) - excessive capabilities (same) - CAP_SYS_ADMIN (same) - CAP_SYS_PTRACE (same) - DAC_READ_SEARCH (same) - Docker socket exposure (same) - sensitive host path mounts (same) - CVE-2022-0847 (valid. https://www.docker.com/blog/vulnerability-alert-avoiding-dir...) - CVE-2022-0185 (mitigated by default Docker config, requires miconfiguration of capabilities) - CVE-2021-22555 (mitigated by default Docker config, requires miconfiguration of seccomp filters) default seccomp filters in docker: https://docs.docker.com/engine/security/seccomp/#significant... privileges that are dropped: https://docs.docker.com/engine/containers/run/#runtime-privi... --- I'll add this: Containers aren't as strong of a security boundary as VMs however this means that a successful attack now requires infection of the container AND a concurrent container-escape vulnerability. That's a really high bar, someone would need to burn a 0-day on that. The bar right now is really, really low - blocking post-install scripts seems to be treated as "good enough" by most. Using a container-based sandbox is going to be infinitely better than not using one at all, and container-based solutions have a much easier time integrating with other tools and IDEs which is important for adoption. The usability and resource consumption trade-off that comes with VMs is pretty bad. Just don't commit any mortal sins of container misconfigurations - don't mount the Docker socket inside the container (tempting when you're trying to build container images inside a container!), don't use --privileged, don't mount any host paths other than the project folder. |
AFAIK a comprehensive SELinux policy (like Red Hat ships) set to enforce will also prevent quite a few file accesses or modifications from escapes.