Oh and the Docker patch was committed on Jan 9, so this has been known for at least a month in some circles. "Nice".
@x_cli One question about the proper use of containers (*not* VM, only containers). Is it reasonable to give root access in a container to someone who is not root on the host? I always thought the answer was No and this is how I manage containers. The report mention "public cloud service". Are there services where tenants have root access to a container?
The answer is here:
"A common practice is to add users that need to run Docker containers on your host to the docker group. [...] What is not obvious right away is that this is basically the same as giving those users root access. You see, the Docker daemon runs as root and when you add users to the docker group, they get full access over the Docker daemon."
Correct. You are expected to map the in-container root to an unpriv user on the parent NS. If the mapping maps in-container root to a user with some privileges on the parent NS, there are some more complex rules applying to what you can and can't do. That's because there are still stuff like mount point locks, and setns restrictions.
@bortzmeyer @ParadeGrotesque @Keltounet
My answer was inaccurate. Even if mapped to an unpriv user, you have to care about mount point locks and setns restrictions and all of that "good" stuff, but things get even muddier when mapped to a user able to get some privileges and then, I'm not sure what happens.
Do you know about user namespaces? Their root is not privileged in their parent user namespace (if there is UID/GID mapping).
@x_cli OK, new things to learn, it seems.
That will be the topic of my new MISC article, published in march or may.
Unfortunately many use cases require some kind of privileges inside the container, starting with privilege drop itself when running a daemon that requires different levels of privilege for listening on a port, writing to logs or serving requests.
User namespaces offer useful features and can hopefully be combined with fine-tuned caps and seccomp to "safely" offer "root" inside the container.
@x_cli We should obviously not. But services who rent containers as full-featured "VPS" want their tenant to be able to run.. Apache for instance. This either requires to fine-tune a user namespace and capability assignment so that the container can have a namespaced root user, listen on a privileged port, then setuid to a less privileged user ; or to provide basic unrestricted root access in the container. Guess what happens most of the time :)
@bortzmeyer root != root. root in container != real root. Some of the slides from this "ignite" talk at #cfgmgmtcamp may interest you. https://www.slideshare.net/frank_be/docker-security-101-cfgmgmtcamp-2019
A Mastodon instance for info/cyber security-minded people.