Date: Mon, 8 Jan 2018 12:36:10 -0600 From: "Serge E. Hallyn" <serge@...lyn.com> To: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com> Cc: "Serge E. Hallyn" <serge@...lyn.com>, James Morris <james.l.morris@...cle.com>, LKML <linux-kernel@...r.kernel.org>, Netdev <netdev@...r.kernel.org>, Kernel-hardening <kernel-hardening@...ts.openwall.com>, Linux API <linux-api@...r.kernel.org>, Kees Cook <keescook@...omium.org>, "Eric W . Biederman" <ebiederm@...ssion.com>, Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>, Mahesh Bandewar <mahesh@...dewar.net> Subject: Re: [PATCHv3 0/2] capability controlled user-namespaces Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com): > On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@...lyn.com> wrote: > > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com): > >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@...lyn.com> wrote: > >> > Quoting James Morris (james.l.morris@...cle.com): > >> >> 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 > >> > > >> >> 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. > 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. > > > 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. > > > 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.