Making containers safer [LWN.net]

Making containers safer

Posted Aug 21, 2019 22:09 UTC (Wed) by rc (subscriber, #108304)
In reply to: Making containers safer by brauner
Parent article: Making containers safer

Why is that bad practice? Only use what you need, right? Some of the solutions use a user namespace to set up the mounts so it can all be done by an unprivileged user rather than a setuid process (or with capabilities).

Unless I'm missing something, that sounds ideal. (And yes, I agree with others who are concerned about the increased kernel attack surface of user namespaces)

to post comments

Making containers safer

Posted Aug 22, 2019 13:02 UTC (Thu) by cyphar (subscriber, #110703) [Link] (2 responses)

> Why is that bad practice? Only use what you need, right?

Not using security features is not a form of "principle of least privilege", it's an example of worrisome (if not outright bad) engineering.

> And yes, I agree with others who are concerned about the increased kernel attack surface of user namespaces.

The attack surface is increased by setting CONFIG_USER_NS=y in your kernel config. Using them to contain workloads on a machine that has CONFIG_USER_NS=y does not increase the attack surface, because even if you don't use them the container could call unshare(CLONE_NEWUSER) itself. In addition, most container runtimes block CLONE_NEWUSER with seccomp by default.

Making containers safer

Posted Aug 22, 2019 17:54 UTC (Thu) by rc (subscriber, #108304) [Link] (1 responses)

I'm still not understanding this so maybe I'll explain where I'm coming from and see if that helps. I am specifically referring to HPC. HPC environments (with some rare exceptions) are multi-user environments. There can be dozens or hundreds of people logged into the same systems at any moment. Job schedulers are used to farm out work to various compute nodes (node==server in HPC parlance, just to be clear). Many HPC centers allow jobs from different users to be run on the same nodes at the same time, assuming there are enough resources available.

Generally, in HPC the desire to use containers is not to run containers. The desire is to package up terrible software in such a way that it will work. That is all. Some code that users want to run was cobbled together by grad students who barely got the thing running so they could finish up their research and graduate. Then people all over the world want to take that (often) unmaintainable garbage and use it themselves. That's where containers come in. Most code tends to be of decent quality, but it's that garbage software that we want to put in a garbage bin (aka container).

In what way would using namespaces other than the mount or user namespace help? (or using seccomp, etc)? Users can already run arbitrary code so how is allowing arbitrary code *in a container* any worse if it is only using mount or user namespacing? Sure, using the pid or network namespaces could help isolate users from each other, but that's orthogonal since it should be done for *all* user processes and not just containers.

Long story short, I fail to see how this particular usage in HPC somehow makes "run arbitrary code x in a container with mount and user namespacing only, all launched in an unprivileged manner by a normal user" any worse than "run arbitrary program y launched in an unprivileged manner by a normal user not inside a container".

Our goal is to isolate users from each other, not isolate containers from each other or prevent code in containers from escaping into the environment of the user that launched the container.

Making containers safer

Posted Aug 25, 2019 20:27 UTC (Sun) by jgg (subscriber, #55211) [Link]

I've said before that HPC people should not call their use of Mount namespaces to package software 'contianers' - it just confuses people. It is much closer to flat pack and snap, IMHO.