I actually don't know who is misunderstanding who here. I work with containers daily and this is how I understand this situation:
The runner (trusted code) is tasked with taking job specifications from the user (untrusted code) and running them in isolated environments. Correct?
The runner is in a container with a mounted docker socket. It sends a /containers/create request to the socket. It passes a base image, some resource limits and maybe a directory mount for the checked out repository (untrusted code). The code could alternatively be copied instead of mounted. Correct?
The new container is created by dockerd without the socket mounted, because that wasn't specified by the runner ("Volumes": [] or maybe ["/whatever/user/repo/:/repo/"]). Correct?
The untrusted code is now executed inside that container. Because the container was created with no special mounts or privileges, it is as isolated as if it was created manually with docker run. Correct?
The job finishes executing, the runner uses the socket to collect the logs and artifacts, then it destroys the container. Correct?
So please tell me how you think untrusted code could get access to the socket here?
I read you both late to say this but you were misunderstanding each other fundamentally because no one stated it clearly (until this last message) what is trusted code. You consider OneDev as trusted, the other user does not. Given the recent track record of vulnerable dependencies in FOSS (and everywhere really), I would also consider that the platform software itself must be considered as untrusted, and user guides should only request for advanced permissions as long as they also instruct to install everything in an isolated VM.
I agree it should be in a VM and it would be great to put that in the documentation, but the reality usually is that your CI/CD tool will already have very elevated access to your infra. The people deploying using docker compose are usually not the kind of people that have tightly scoped deployment credentials. If someone can get into your CD system, they can almost certainly run arbitrary code on your production machines.
The runner (trusted code) is tasked with taking job specifications from the user (untrusted code) and running them in isolated environments. Correct?
The runner is in a container with a mounted docker socket. It sends a /containers/create request to the socket. It passes a base image, some resource limits and maybe a directory mount for the checked out repository (untrusted code). The code could alternatively be copied instead of mounted. Correct?
The new container is created by dockerd without the socket mounted, because that wasn't specified by the runner ("Volumes": [] or maybe ["/whatever/user/repo/:/repo/"]). Correct?
The untrusted code is now executed inside that container. Because the container was created with no special mounts or privileges, it is as isolated as if it was created manually with docker run. Correct?
The job finishes executing, the runner uses the socket to collect the logs and artifacts, then it destroys the container. Correct?
So please tell me how you think untrusted code could get access to the socket here?