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

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.