Hacker News Reader

Comment by zibzab | Hacker News Reader

There are _some_ containers that are security mechanism.

Docker is definitely not one of them. But LXD for example uses unprivileged containers by default and can be hardened with additional software for syscall filtering

View on HN

> uses unprivileged containers by default and can be hardened with additional software for syscall filtering

You also described docker.

I agree that docker's main focus isn't to be a security oriented sandbox, but perhaps you need to find a different wording of what exactly makes LXD (or others) so different.

> You also described docker.

Can docker do secure multiuser?

https://m.youtube.com/watch?v=6O0q3rSWr8A

If LXD also uses cgroups and Linux namespaces it seems like the differences would be pretty small? Docker also allows custom syscall filtering, unprivileged containers, etc.

I think the reality is just that containers will always be imperfect, and you should understand that risk when building systems.

I was under the understanding that docker didn't use user namespaces by default -- so "root" in the container is the same user as "root" outside the container -- but that LXD does. Has that changed?

It doesn't but TBH user namespaces have a mixed record when it comes to security. For example CVE-2022-0185 wasn't exploitable from a standard container unless user namespaces were available allowing additional capabilities to be gained, inside that user namespace (https://blog.aquasec.com/cve-2022-0185-linux-kernel-containe... has more details.

My biggest concern is how docker's default behavior is to run roughshod over traditional unix security. Usually, adding a user to a group grants them some additional files or devices. The expectation is that adding a user to the "docker" group would allow that user to interact with the docker daemon, and that the docker daemon would check user-level privileges internally. Instead, adding a user to the "docker" group allows a user to have passwordless root-level privileges to access or modify any file on the system, regardless of file ownership (e.g. `docker run --volume /:/mnt ubuntu cat /mnt/etc/shadow`).

There's some documentation on how only trusted users should be given access to the docker daemon, but I do not consider it sufficient. At no point in the installation or getting started documents [0,1] is it mentioned that it drives a gaping hole through existing security measures. Instead, the mention was on the security page, three sections down in a discussion about the attack surface [2]. This is the sort of issue that should be in big bold blinking letters at the top of every tutorial, that access to docker is

I know that rootless docker exists and improves this situation, but it is neither the default behavior, nor the introductory example in official documentation. I know that docker's primary role is dependency management, and that it only considers escalation coming from within the container as security issues. But there's a world of difference between "I'm not a locksmith, so I don't sell locks." and "I'm not a locksmith, so I break in your windows." One is ambivalent to existing security measures, while the other, like Docker, actively subverts them.

[0] https://docs.docker.com/get-started/

[1] https://docs.docker.com/engine/install/

[2] https://docs.docker.com/engine/security/#docker-daemon-attac...

Edit: When I was initially researching this, because I was absolutely floored that this security flaw was even a possibility in something as widely used as docker, I came across this reddit post [3], which explains the issue quite well. It is 4 years old and predates rootless docker, but is still accurate to the default and most widely used behavior.

[3] https://www.reddit.com/r/docker/comments/7y2yp2/why_is_singu...

Reply on news.ycombinator.com