Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

onedev.io

Post reply on HN
Print view View original

51–60 of 67 posts

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#51

Post by franga2000 »

soraminazuki wrote: post #47
mbreese wrote: post #41

Earlier quoted context omitted.

If you want to be able to spin up CI/CD containers, don’t you kinda already need to have docker socket access? In that case, you’ve already decided that this isn’t a threat vector you’re concerned about. Yes, this probably makes it easier, but the ability to startup new containers for CI/CD is what makes this threat possible. So, I’m not sure this is something I’d worry much about. Perhaps they should flag this in th…

It's a multi-user Git / CI /CD / project management platform. If you introduce this in your organization, a single vulnerability can take down the entire system and any other application running on the same host. You can't just "decide that this isn’t a threat vector" without taking the use case into account. Or at least it should come with alarm bells warning users that it's unsafe.

What is "entire system" here? I'd run something like that in a VM, so the "entire system" would be nothing but the app itself.

If there is a RCE vuln in the app, your users are just as unsafe if it's running as root on the host or if it's running as nobody in a container. The valuable data is all inside.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#52

Post by franga2000 »

zenoprax wrote: post #43
mbreese wrote: post #41

Earlier quoted context omitted.

If you want to be able to spin up CI/CD containers, don’t you kinda already need to have docker socket access? In that case, you’ve already decided that this isn’t a threat vector you’re concerned about. Yes, this probably makes it easier, but the ability to startup new containers for CI/CD is what makes this threat possible. So, I’m not sure this is something I’d worry much about. Perhaps they should flag this in th…

Running a binary as a non-root user with scoped access to Docker commands seems more appropriate to me.

What do you mean by scoped access? A bunch of regexes checking that the app doesn't add any dangerous flags to docker run? That sounds like a fun CTF challenge to me, which is not a good thing for a security feature...

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#53

Post by franga2000 »

soraminazuki wrote: post #39
franga2000 wrote: post #34

Earlier quoted context omitted.

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

It's poor security practice that shouldn't be overlooked. Mounting the Docker socket effectively allows the entire application to run with root privileges on the host. Given that this seems to be a multi-tenant application, the implications are even more concerning. The component responsible for spinning up CI/CD containers shouldn't operate within the security boundary of the rest of the application. On a related no…

No shit, I don't know why everyone is trying to explain Docker basics to me. All I'm saying is that socket access is required to spin up containers and it's nothing out of the ordinary for this use case.

Of course it's an issue if you're using Docker to isolate OneDev from the rest of the apps running on your systems. But that's not everyone's use-case. Anything that intentionally spins up user-controlled containers should be isolated in a VM. That's how every sane person runs GitLab runners, for example.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#54

Post by ranguna »

hamdingers wrote: post #28

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose…

Iirc that's how gitlab runners does this as well. Not saying that just because someone else does, it makes it ok, but just putting it out there.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#55

Post by fluidcruft »

hamdingers wrote: post #38
franga2000 wrote: post #34

Earlier quoted context omitted.

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

> It breaks the isolation for that one container, the rest are just fine. Wrong. A container with access to the socket can compromise any other container, and start new containers with privileged access to the host system. It compromises everything. This is a risk worth flagging.

Would rootless docker help? (Potentially even running that specific workflow with it's own dedicated user)

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#56

Post by cassianoleal »

franga2000 wrote: post #50
hamdingers wrote: post #38

Earlier quoted context omitted.

> It breaks the isolation for that one container, the rest are just fine. Wrong. A container with access to the socket can compromise any other container, and start new containers with privileged access to the host system. It compromises everything. This is a risk worth flagging.

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.

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

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#57

Post by franga2000 »

cassianoleal wrote: post #56
franga2000 wrote: post #50

Earlier quoted context omitted.

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.

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

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.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#58

Post by hamdingers »

franga2000 wrote: post #57
cassianoleal wrote: post #56

Earlier quoted context omitted.

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

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.

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"

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#59

Post by franga2000 »

hamdingers wrote: post #58
franga2000 wrote: post #57

Earlier quoted context omitted.

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.

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 contain…

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.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#60

Post by hamdingers »

franga2000 wrote: post #59
hamdingers wrote: post #58

Earlier quoted context omitted.

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 contain…

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.

> 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.

Post reply on HN