Hacker News Reader

Comment by tpetry | Hacker News Reader

Any of the capabilities needed by the exploits is in linux only available to root users. And are now granted to a container.

So these ”escapes“ are basically giving a container full access to the host and using that. None of them are enabled by default.

View on HN

Raymond Chen had a blog post complaining of bug reports that started with - assuming the attacker has root access...

unfortunately cannot find it anymore.

on edit - maybe it was write permissions to the file system, but largely the same level of "once you have this it is game over"

“It rather involved being on the other side of this airtight hatchway” - there’s a couple posts in the series.

https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

In practice, though, containers are given these capabilities all the time, and in infosec people do refer to these as escapes.

Generally, it’s not the stuff the container is intended to run that’s doing the escape, though. This is usually the second step, after getting local execution through a vulnerability in the application running in the container.

Why are these capabilities usually granted, in your experience?

User error is the source of many vulnerabilities that shouldn't exist.

I posted another comment with some examples, but I think the general answer, IME, is that it's usually easier to do the wrong thing than to do the right thing. Security boundaries in Cloud-style Linux are typically hard to configure and not well documented. Engineers have deadlines and they're interested in building things, not debugging permissions. They'll do whatever is the easiest to get the system working.

This, by the way, is why I think Google had it right by splitting most products into SWE and SRE groups, so you had a group of people who could focus full-time on the production environment. SWEs are rewarded for building and deploying stuff, so they're going to build and deploy stuff.

In my experience profilers often need SYS_ADMIN or other capabilities. This is true even outside of a container. If I'm forced to work inside a container without the ability to add that cap, performance optimization work becomes very difficult.

That's not true, those capabilities can be granted to normal users. If the container is badly composed enough, sys admins might grant a user those caps so they can avoid security alerts about running containers as root.

Which is relevant because containerd most commonly runs as root, even in Kubernetes.

It doesn't matter, the "root" user inside the container is still jailed and none of these tricks will allow that user to escape.

Actually, no. The root in container isn't actually uid 0 in host system if you setup things correctly. Linux user namespace can offset uid in a container by certain number. Effectively make uid 0 actually uid 60000, uid 1000 as uid 61000 and so on.

And in this case. If you escaped the container, you are literally nobody. All you allowed to read is public files that any user can read.

By the way. If you use rootless container, this is the default settings you will get. Since you don't have access to uid0 at first place.

>if you setup things correctly

Judging by the number of HOWTOs I see on GitHub and YouTube that tell you to check the Privileged box, this assumption isn't worth what you think it is.

You're correct in that uid 0 in the container is faked through userns, but you can easily bypass that with a privileged container or adding the CAP_ADMIN capability. Yes, you can disable creating privileged containers within Kubernetes, but that isn't something you can rely on. If the runtime is running as root, which it often is, you can also become real root within the container under these conditions.

Reply on news.ycombinator.com