Hacker News Reader

Hacker News

Comment by remram | Hacker News Reader

Parent Full thread

remram

1 and 7 need SYS_ADMIN, not available by default in any container runtime.

2 needs Docker socket, it's explicitly meant for running other workloads

3 needs shared PID namespace in addition to SYS_PTRACE, neither is granted by default by any container runtime

4 needs SYS_MODULE, again no one has that

5 and 6 need DAC_READ_SEARCH, no one grants that, no one uses that

None of those seem like vulnerabilities or things that would be available without the admin taking explicit steps to specifically want to allow escaping. Being root in the container would not be enough to get any of those capabilities.

View on HN

I've seen people who use testcontainers and run their CI workloads in containers abusing the docker.sock mounting so they can spin up the tests. The anti-pattern of using docker.sock has been always a threat because when docker got popularity in CI/CD systems it was the easiest way to have a platform independent way to spin up isolated environments. In my perception, this was a very common pattern in Jenkins a few years ago.

A workaround for this is to run Docker Engine inside a (non-Docker) container and use that container's socket. The Docker containers become processes within the Docker Engine container.

AFAIK you can't do that without giving the Docker-in-Docker container privileged permissions, which allows escaping.

You can do what Docker Desktop does- put the whole thing in a VM :^)

You still can't run untrusted code but at least you can isolate stuff like Compose environments

Exactly! This is a huge pet peeve of mine. I feel like I'm going crazy when I read articles like this one (that is, any of the similar "how to escape containers" blog posts). With the exception of a rare few that actually describe 0-days, the overwhelming majority seem to be exactly like this.

It confuses the heck out of me because red-team-type people will shout from the mountaintops about how insecure containers are and how absolutely trivial it is to break out of them, but when I go look for an example of that trivialness, all I find is stuff like this. Not that these aren't at all useful techniques - there are plenty of containers with --privileged, or a Docker socket mount, etc. But surely this doesn't apply to >90% of containers out there, especially ones that are exposed to the Internet. Your average Redis or Nginx container, or some container running a Python or Node webapp, is not going to have Docker mounted or some weird capability added. Sure, misconfigs happen, us sysadmins get lazy, but this is really common-sense stuff. It feels almost unfair to "blame" it on the container.

Of course, as mentioned, there are 0-days that allow for container breakout, and those are the truly scary stuff. But they seem to be few and far between, and they get publicized semi-widely and patched pretty quickly when they are found.

So to this day I don't really understand all the security folks who act like they (as in any decent attacker, not just a nation-state with 0days up the wazoo) could break out of a container with their eyes closed, while the only material I can find on the open Internet is stuff like this. Am I just looking in the wrong places?

But these caps aren't extraordinary — in particular I find often that using profilers and the like often requires them. E.g. the manual for Nvidia Nsight specifically tells you to add SYS_ADMIN, which as we see here breaks the seal. Ergo we can _either_ be able to run those tools, _or_ have a safe containerized workflow: that dichotomy alone is useful enough to justify this article IMO

That's fair! That's a good point, and I don't mean to invalidate those situations.

A part of me still feels like that's somewhat separate from a "typical" scenario where you want to harden a container that's exposed to the outside world in some way; like I said, your average container running a webapp or whatever. Nvidia Insight seems to be a performance analysis tool, so I would hope nobody is running it with untrusted input or exposing it to the Internet. (Yes, I know someone out there totally is.)

Similarly, it feels near-obvious to me that adding a privilege called "SYS_ADMIN" to a container will make it more or less equivalent to root on the host. It's not like Docker hides this info from people, last I checked it's explained pretty prominently.

You're totally right overall, it still matters, it's just something about this framing that rubs me the wrong way.

> to specifically want to allow escaping

Not really unfortunately. A novice sysadmin granting someone's request to add some permission called SYS_MODULE may not know that it could be equivalent to full root access. That's why posts like this are important for education.

> A novice sysadmin granting someone's request to [give them root in an obscure, sneaky manner]

...is a social engineering exploit, not a technical one.

To pose an alternative scenario:

> A novice sysadmin granting someone's request to [be able to run some tool/software that says it needs this, but is in fact secretly malicious]

or perhaps more common

> A novice sysadmin granting someone's request to [be able to run some legitimate tool or software, then later a virus in the container taking advantage and breaking out]

for a real world example, the Nvidia Nsight docs specifically direct you to add SYS_ADMIN; do you think your everyday ML engineer would know that doing so poses a security risk if they're doing this on Docker?

As someone who works in security (both pre-fail and post-fail), 95% of incidents happen because things are not configured correctly. Actual vulnerabilities in Linux are expensive, and any attacker competent enough to have one, also will not burn it needlessly, if they can get in because a SWE with a deadline gave the container SYS_PTRACE.

I think your response betrays a broken line of communication in our industry. People tend to assume most production environments are configured by people who knew what they were doing, were deploying a well-behaved application and had time and management support to do a good job. That's almost never the case, even in well-funded, well-regarded tech companies.

Reply on news.ycombinator.com