5 ms·

Read this: https://kayssel.substack.com/p/docker-escape-breaking-out-of-containers https://kayssel.substack.com/p/docker-escape-breaking-out-of...

by lmc 6mo ago

ashishb 6mo ago
So the worst case is that you are back to running npm on your host. Right?
dns_snek 6mo ago
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-dirty-pipe-cve-2022-0847-on-docker-engine-and-docker-desktop/ 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-syscalls-blocked-by-the-default-profile https://docs.docker.com/engine/security/seccomp/#significant... privileges that are dropped: https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities 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.
- kajman 6mo ago
  I don't think it's crazy to imagine a misconfigured production environment. I always see these same examples of how "containers aren't really secure" and they're very amateur sins to commit though, as you mention. AFAIK a comprehensive SELinux policy (like Red Hat ships) set to enforce will also prevent quite a few file accesses or modifications from escapes.

Read this: https://kayssel.substack.com/p/docker-escape-breaking-out-of-containers https://kayssel.substack.com/p/docker-escape-breaking-out-of...

by lmc 6mo ago

Read this: https://kayssel.substack.com/p/docker-escape-breaking-out-of-containers https://kayssel.substack.com/p/docker-escape-breaking-out-of...

ashishb 6mo ago

So the worst case is that you are back to running npm on your host. Right?

dns_snek 6mo ago

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-dirty-pipe-cve-2022-0847-on-docker-engine-and-docker-desktop/ 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-syscalls-blocked-by-the-default-profile https://docs.docker.com/engine/security/seccomp/#significant... privileges that are dropped: https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities 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.

kajman 6mo ago
I don't think it's crazy to imagine a misconfigured production environment. I always see these same examples of how "containers aren't really secure" and they're very amateur sins to commit though, as you mention. AFAIK a comprehensive SELinux policy (like Red Hat ships) set to enforce will also prevent quite a few file accesses or modifications from escapes.