Live data from Hacker News

Escaping privileged containers for fun

pwning.systems

21–30 of 42 posts

Re: Escaping privileged containers for fun

#21
post #2

I use AppArmour and use Podman rootless for everything that needs to be containerized so it's all good for me anyway :) Fun read! Maybe put an RSS button somewhere so it's easier to subscribe to?

> Podman rootless This is the way. Docker rootless and podman rootless. A lot less attack surface than running containers as root. I haven't tried a dedicated user for this though. I'm sure that mounting volumes would get messed up.

I run services like Plex or DNS adblocker in this manner. Each service gets its own user to run rootless under and inside the container the app doesn't run as root.

Security is layers.

Re: Escaping privileged containers for fun

#22
post #4

Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.

https://www.redhat.com/sysadmin/basic-security-principles-co...

Re: Escaping privileged containers for fun

#24
post #6

Earlier quoted context omitted.

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

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.

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...

Re: Escaping privileged containers for fun

#26
post #4

Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.

Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…

Why is the Linux kernel garbage? I thought Linux had decent security chops?

Re: Escaping privileged containers for fun

#27
post #4

Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.

These days, Docker doesn't care about the underlying container runtime. You can use Docker to run containers in VMs with Firecracker, gVisor, Kata, etc. Security and multitenancy are their raison d'être.

You might have been right in 2014. In 2022, containers are most definitely a security mechanism.

Re: Escaping privileged containers for fun

#28
post #4

Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.

Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…

Unless you have a secure mechanism to forbid containers from running with `--privileged` (which does not come with container runtimes that I'm aware of), or unless your container runtime launches a VM to run the containers in, then the conception of containers being a security mechanism is a pretty thin one, indeed.

Containers can be part of a secure application runtime environment, but much like sugary cereal can be a part of a balanced breakfast, more is required.

Re: Escaping privileged containers for fun

#29

Earlier quoted context omitted.

Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…

Why is the Linux kernel garbage? I thought Linux had decent security chops?

Written in C, huge codebase, decades of alienating security researchers, etc.

Re: Escaping privileged containers for fun

#30

Earlier quoted context omitted.

Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…

Unless you have a secure mechanism to forbid containers from running with `--privileged` (which does not come with container runtimes that I'm aware of), or unless your container runtime launches a VM to run the containers in, then the conception of containers being a security mechanism is a pretty thin one, indeed. Containers can be part of a secure application runtime environment, but much like sugary cereal can be…

Attackers have no control over the --privileged flag, so what you're basically asking for is a lint that greps for "--privileged" and fails CI if it finds it.

Some things may make this harder, like Kubernetes presumably, but idk it seems relatively straightforward and also not exactly the fault of containers.

Post reply on HN