security: make all run without root privileges

[mota-lhd]

maybe using podman instead of docker ?

[gregsadetsky]

thanks a lot for the suggestion! Disco is pretty tied to Docker right now, so that change would unfortunately be impossible in the short term.

(there are also other concerns, like Disco needing to bind itself to ports 80 and 443, etc. - nothing is strictly impossible, but yeah, we do assume sudo right now)

could you let us know about your use case / what you wanted to use Disco for? are you in an environment that does not have root/sudo for instance? thanks!

[mota-lhd]

For the moment I am testing the tool for my own VPS. This is something blocking for me in a professional environment where security best practices need to be in place. The main reason is because the disco.cloud Fastapi REST API is exposed on the caddy reverse proxy. If there is a RCE vulnerability on disco.cloud API then the hacker is directly root on the servers.

We can for example use linux capabilities to authorise the network admin part and reduce the risk.

I love your project by the way and I am talking about it around me :D

[gregsadetsky]

Thanks for the explanation! It's worth considering for sure. In a way, we're in the same boat here as Caddy and others that do need to bind themselves to ports 80 and 443 (ie under 1024) which, at some point, do require sudo/root privileges.

Right now, our main mitigation is that the (fastapi) daemon itself runs inside a docker container. If there were a RCE vulnerability, the attacker would be contained within that container first, not directly root on the host.

It might be possible to go down the route of a non-root Docker and a non-root Caddy (which seems to be supported) with elevated privileges for port binding only, though that would be a bigger architectural change. I think it's worth exploring how difficult that might be, and what would be the implications of that.

[mota-lhd]

it is absolutely possible for a root user inside a Docker container to escalate privileges to gain root on the host system :)

while Docker provides isolation through namespaces and cgroups, it is not a completely secure, bulletproof sandbox. a root user inside a container has significant power and can exploit several avenues to break out to the host.

this is possible through

mounting the host filesystem

this is the most straightforward and common way. if the container is run with a volume mount that gives it access to a critical part of the host filesystem, root inside the container can modify host files.

like mounting /, /etc or /var/run can be enough to cause serious harm.

exposing the docker socket (/var/run/docker.sock)

extremely common and dangerous misconfiguration. anyone with write access to this socket can issue any docker command.

example:

# DANGEROUS: this is actually what disco does
docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu bash

inside the container, an attacker who compromised an app can install the docker CLI and then run:

# from inside the container, start a new container that has the host's / filesystem mounted.
docker run -it -v /:/host ubuntu bash

this works because the Docker daemon runs as root on the host. By controlling the socket, you control the daemon.

less common: kernel exploits

the container and the host share the same Linux kernel. if there is a vulnerability in the kernel (e.g., a flaw in a namespace, cgroup, or syscall), an attacker with root in the container can run an exploit against the host kernel to gain root privileges on the host.

---

best practices to prevent this

1. run as a non-root user: never run your application as root inside the container if you can avoid it.
2. use user namespaces: remap the container's root user to a high-numbered, non-privileged user on the host. this means even if an attacker gets root in the container, they are just an unprivileged user (like UID 100000) on the host.
3. never mount the docker socket: unless you are running a container that explicitly needs to manage the docker daemon (like Portainer or a CI/CD runner), never mount the docker socket into a container.
4. drop all capabilities and add back only needed ones: use the --cap-drop=ALL and --cap-add flags to provide a minimal set of capabilities.

   docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-image

[gregsadetsky]

That's a great point, and thanks for the detailed explanation. You're correct, my initial thinking was flawed.

With the Docker socket mounted, an RCE vulnerability would indeed potentially allow an attacker to escape the container and get root on the host. The container itself isn't a sufficient security boundary in this specific setup. We need to be clearer that disco is a privileged component, and the real security boundary is preventing the initial compromise of its API.

Your feedback makes me think we should investigate using a Docker socket proxy. That would let us create an allow-list for only the API calls that disco absolutely needs, which could be a step in reducing the attack surface. Obviously, feel free to chime in if you have other thoughts/suggestions here.

Thanks again for pushing on this!