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?

@Keltounet @x_cli ? I don't see the relationship. Let me ask again: are there *services* (not software) where *tenants* (not the company managing the service) have root access to a container?

@bortzmeyer @x_cli it has been known in the BSD world to offer hosting with shell access, including root.

@bortzmeyer @Keltounet @x_cli

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


Unless I did not understand your question at all. In which case, please accept all my apologies.

@Keltounet @x_cli

You are talking about giving a user docker command access. Stéphane was asking about root priv inside the container (which is "safe" if you use user namespaces, and preferably also seccomp, and a LSM)
@bortzmeyer @Keltounet

@x_cli @ParadeGrotesque @Keltounet Safe only if root-in-the-container is not mapped to some priviledged stuff like system:admin, no?

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.
@ParadeGrotesque @Keltounet

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

Basically, OVH VPS (which are containers) grant root priv on the guest, for instance.

@x_cli @bortzmeyer is KVM impacted? At least one VPS provider with root access uses KVM for their machines (Vultr).

@bortzmeyer @x_cli Right, it is virtualisation, not containers.

One gets confused sometimes with the linux world :)

Do you know about user namespaces? Their root is not privileged in their parent user namespace (if there is UID/GID mapping).

That will be the topic of my new MISC article, published in march or may.

@x_cli @bortzmeyer @x_cli that's not how docker security works. That's not even how Linux user namespaces work. None of it was built for security

Please enlighten me instead of shitting on my answer without providing any other "value".

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.

@kaiyou @x_cli My point was not "we shoud not give root access inside the container" but "we should not give root access to someone who is not already root" (I use containers, but not in a multi-tenant configuration).

@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. slideshare.net/frank_be/docker


@x_cli learn 👏🏼 how 👏🏼 to 👏🏼 container 👏🏼 linux 👏🏼 you’re 👏🏼 embarrassing
Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.