4 ms·

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 s

by minitech 10mo ago

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 10mo ago
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 10mo ago
  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/ 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.
  - deleted 10mo ago
    [deleted]
- 3np 10mo ago
  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 10mo ago
  Podman makes this easier to do safely by default. I'd suggest checking that out.

czbond 10mo ago

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 10mo ago
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/ 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.
- deleted 10mo ago
  [deleted]
3np 10mo ago
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 10mo ago
Podman makes this easier to do safely by default. I'd suggest checking that out.