On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn [off-list ref] wrote:

Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):

quoted

On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn [off-list ref] wrote:

quoted

Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):

quoted

On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn [off-list ref] wrote:

quoted

Quoting James Morris (james.l.morris@oracle.com):

quoted

On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
I meant in terms of "marking" a user ns as "controlled" type -- it's
unnecessary jargon from an end user point of view.

Ah, yes, that was my point in

http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
and
http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html

quoted

This may happen internally but don't make it a special case with a
different name and don't bother users with internal concepts: simply
implement capability whitelists with the default having equivalent

So the challenge is to have unprivileged users be contained, while
allowing trusted workloads in containers created by a root user to
bypass the restriction.

Now, the current proposal actually doesn't support a root user starting
an application that it doesn't quite trust in such a way that it *is*
subject to the whitelist.

Well, this is not hard since root process can spawn another process
and loose privileges before creating user-ns to be controlled by the
whitelist.

It would have to drop cap_sys_admin for the container to be marked as
"controlled", which may prevent the container runtime from properly starting
the container.

Yes, but that's a conflict of trusted operations (that requires
SYS_ADMIN) and untrusted processes it may spawn.

quoted

You need an ability to preserve the creation of user-namespaces that
exhibit 'the uncontrolled behavior' and only trusted/privileged (root)
user should have it which is maintained here.

quoted

Which is unfortunate.  But apart from using
ptags or a cgroup, I can't think of a good way to get us everything we
want:

1. unprivileged users always restricted
2. existing unprivileged containers become restricted when whitelist
is enabled
3. privileged users are able to create containers which are not restricted

all this is achieved by the patch-set without any changes to the
application with the above knob.

quoted

4. privileged users are able to create containers which *are* restricted

With this patch-set; the root user process can fork another process
with less privileges before creating a user-ns if the exec-ed process
cannot be trusted. So there is a way with little modification as
opposed to nothing available at this moment for this scenario.