[ashishb]

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]

By all means, run your npm in docker, but please stop telling others it's a secure way to do so.

[ashishb]

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]

Those aren't the only options, my dude.

[ashishb]

And what are good options that you use and that work on Linux as well as Mac OS?

[lmc]

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

[ashishb]

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

[dns_snek]

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.

[kajman]

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.