On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@xxxxxxxxxx): >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: >> > Quoting James Morris (james.l.morris@xxxxxxxxxx): >> >> 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
