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 the documentation as something to be noted, but otherwise, I’m not sure how else you get this functionality. Is there another way?

▲

soraminazuki 2 days ago | parent | next [-]

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.

	▲	franga2000 2 days ago \| parent [-]
		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.

▲

hebocon 2 days ago | parent | prev [-]

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

	▲	franga2000 2 days ago \| parent [-]
		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...