4 ms·

Docker is not a strong security boundary and shouldn't be used to sandbox like this https://cloud.google.com/blog/products/gcp/exploring-container-security-an-

by lmc 6mo ago

Docker is not a strong security boundary and shouldn't be used to sandbox like this https://cloud.google.com/blog/products/gcp/exploring-container-security-an-overview https://cloud.google.com/blog/products/gcp/exploring-contain...

ashishb 6mo ago
Compared to what? Which one is superior? Running npm on your dev machine? Or running npm inside Docker? I would always prefer the latter but would love to know what your approach to security is that's better than running npm inside Docker.
- 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.
- lmc 6mo ago
  By all means, run your npm in docker, but please stop telling others it's a secure way to do so.
  - ashishb 6mo ago
    I only said it is a defense-in-depth measure. I definitely want to know how is it worse than running npm directly on the host
    - habinero 6mo ago
      Those aren't the only options, my dude.
      - ashishb 6mo ago
        And what are good options that you use and that work on Linux as well as Mac OS?
EE84M3i 6mo ago
Confusingly, Docker now has a product called "Docker Sandboxes" [1] which claims to use "microVMs" for sandboxing (separate VM per "agent"), so it's unclear to me if those rely on the same trust boundaries that traditional docker containers do (namespaces, seccomp, capabilities, etc), or if they expect the VM to be the trust boundary. [1]: https://www.docker.com/products/docker-sandboxes/ https://www.docker.com/products/docker-sandboxes/

by lmc 6mo ago

ashishb 6mo ago

Compared to what? Which one is superior? Running npm on your dev machine? Or running npm inside Docker? I would always prefer the latter but would love to know what your approach to security is that's better than running npm inside Docker.

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.
lmc 6mo ago
By all means, run your npm in docker, but please stop telling others it's a secure way to do so.
- ashishb 6mo ago
  I only said it is a defense-in-depth measure. I definitely want to know how is it worse than running npm directly on the host
  - habinero 6mo ago
    Those aren't the only options, my dude.
    - ashishb 6mo ago
      And what are good options that you use and that work on Linux as well as Mac OS?

EE84M3i 6mo ago

Confusingly, Docker now has a product called "Docker Sandboxes" [1] which claims to use "microVMs" for sandboxing (separate VM per "agent"), so it's unclear to me if those rely on the same trust boundaries that traditional docker containers do (namespaces, seccomp, capabilities, etc), or if they expect the VM to be the trust boundary. [1]: https://www.docker.com/products/docker-sandboxes/ https://www.docker.com/products/docker-sandboxes/