I think a root container can talk to docker daemon and launch additional containers...with volume mounts of additional parts of file system etc. Not particularly confident about that one though

▲ minitech 5 days ago | parent | next [-]

Unintentional vulnerabilities in Docker and the kernel aside, it can only do that if it has access to the Docker API (usually through a bind mount of the Unix socket). Having access to the Docker API is equivalent to having root on the host.

▲ czbond 5 days ago | parent [-]

Well $hit. I have been using Docker for installing NPM modules in interactive projects I was testing out. I believed Docker blocked access to the underlying host (my computer).

Thanks for mentioning it - but now... how does one deal with this?

▲ minitech 5 days ago | parent | next [-]

If you didn’t mount docker.sock or any directory above it (i.e. / or /run by default) or run your containers as --privileged, you’re probably fine with respect to this angle. I’d still recommend rootless containers under unprivileged users* or VMs for extra comfort. Qubes (https://www.qubes-os.org/) is good, even if it’s a little clunkier than it could be.

* but if you’re used to bind-mounting, they’ll be a hassle

Edit: This is by no means comprehensive, but I feel compelled to point it out specifically for some reason: remember not to mount .git writable, folks! Write access to .git is arbitrary code execution as whoever runs git.

	▲	5 days ago \| parent [-]
		[deleted]

▲ 3np 5 days ago | parent | prev | next [-]

As sibling mentioned, unless you or the runtime explicitly mount the docker socket, this particular scenario shouldn't affect you.

You might still want to tighten things up. Just adding on the "rootless" part - running the container runtime as an unprivileged user on the host instead of root - you also want to run npm/node as unprivileged user inside the container. I still see many defaulting to running as root inside the container since that's the default of most images. OP touches on this.

For rootless podman, this will run as a user with your current uid and map ownership of mounts/volumes:

    podman run -u$(id -u) --userns=keep-id

▲ jcgl 4 days ago | parent | prev [-]

Podman makes this easier to do safely by default. I'd suggest checking that out.

▲ 5 days ago | parent | prev [-]

[deleted]