4 ms·

Yes, that's exactly what I said. The container with the socket is not isolated, but all the other containers are, including the CI containers, which is the whol

by franga2000 1y ago

Yes, that's exactly what I said. The container with the socket is not isolated, but all the other containers are, including the CI containers, which is the whole point.

cassianoleal 1y ago
No containers, existing or potential, are isolated from the one with socket access.
- franga2000 1y ago
  The code inside those containers is isolated, which is the whole point. Only the app or runner container has socket access, which it uses to create new containers without socket access and it runs user code in there. If your get RCE in the app/runner, you get RCE on the host, yes, no shit. But if you get RCE in any other container on the system, you're properly contained.
  - hamdingers 1y ago
    It appears you fundamentally don't understand what mounting the docker socket is doing. I'm sorry to give you homework but you need to go look it up to participate in this conversation. > The code inside those containers is isolated, which is the whole point. A container with socket access can replace code or binaries in any other container, read any containers volumes and environment variables, replace whole containers, etc. That does not meet any definition of "isolated"
    - franga2000 1y ago
      But those containers DON'T have socket access. ONE container has socket access, then it creates other containers WITHOUT socket access. Those containers ARE isolated. Since the untrusted (user provided) code runs in those, the setup is reasonably secure. An RCE in OneDev is an RCE on the host, but that's a completely different threat model. The important part is that user code is isolated, which it is.
      - hamdingers 1y ago
        > The important part is that user code is isolated, which it is. It isn't for the reasons I stated in previous comments, which you are unable to refute. Your dogged insistence to the contrary is bizarre. I hope you do not work in this area.
        franga2000 1y ago
        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?
        deleted 1y ago
        [deleted]
        j1elo 1y ago
        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.

Yes, that's exactly what I said. The container with the socket is not isolated, but all the other containers are, including the CI containers, which is the whole point.

cassianoleal 1y ago

No containers, existing or potential, are isolated from the one with socket access.

franga2000 1y ago
The code inside those containers is isolated, which is the whole point. Only the app or runner container has socket access, which it uses to create new containers without socket access and it runs user code in there. If your get RCE in the app/runner, you get RCE on the host, yes, no shit. But if you get RCE in any other container on the system, you're properly contained.
- hamdingers 1y ago
  It appears you fundamentally don't understand what mounting the docker socket is doing. I'm sorry to give you homework but you need to go look it up to participate in this conversation. > The code inside those containers is isolated, which is the whole point. A container with socket access can replace code or binaries in any other container, read any containers volumes and environment variables, replace whole containers, etc. That does not meet any definition of "isolated"
  - franga2000 1y ago
    But those containers DON'T have socket access. ONE container has socket access, then it creates other containers WITHOUT socket access. Those containers ARE isolated. Since the untrusted (user provided) code runs in those, the setup is reasonably secure. An RCE in OneDev is an RCE on the host, but that's a completely different threat model. The important part is that user code is isolated, which it is.
    - hamdingers 1y ago
      > The important part is that user code is isolated, which it is. It isn't for the reasons I stated in previous comments, which you are unable to refute. Your dogged insistence to the contrary is bizarre. I hope you do not work in this area.
      - franga2000 1y ago
        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?
        deleted 1y ago
        [deleted]
        j1elo 1y ago
        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.