Hacker News Reader

Comment by ashishb | Hacker News Reader

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.

View on HN

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

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

Those aren't the only options, my dude.

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

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

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.

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.

Reply on news.ycombinator.com