[nemanjaboric]

> By default, docker containers run as root which causes a breakout risk. If your container becomes compromised as root it has root access to the host.

Is this really true, unless you start container with `--privileged`? Incidentally, I just read plan for better security defaults to avoid `--privileged` (which is not default, AFAIK) on lwn: https://lwn.net/Articles/755238/

[chrisfosterelli]

Yeah, I believe the quote is incorrect (or at least out of context). If an attacker has access to control the docker daemon like in the attack the article is talking about, then yes that is root [0], but if only a container is exploited then I believe you need one of [1]:

1) an exploit in the kernel,

2) optimistic configuration that allows host access, or

3) a volume mount that exposes something vulnerable like the host root or docker socket.

The quoted article was talking about running within the container as a different user, so I think with context what the article was saying is that _if_ there is a container breakout it's much worse when running root within the container.

[0] https://fosterelli.co/privilege-escalation-via-docker [1] https://security.stackexchange.com/questions/152978/is-it-po...

[blattimwind]

It's about UID mappings between namespaces. When you are UID=0 in namespace X and manage to get out of namespace X, then you are still UID=0 outside X, so you're root.

It's possible to remap UIDs such that root in namespace X has UID=12340, and when root gets out of X, then he's nobody.

[raesene9]

it's not quite as straightforward as just UID mapping. Assuming a standard install of Docker, the container processes only have a limited set of capabilities, have an AppArmor/SELinux profile applied and have a seccomp filter also applied, which makes it harder to break out the the underlying host.