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: >> >> > > Also, why do we need the concept of a controlled user-ns at all, if the >> > > default whitelist maintains existing behavior? >> > >> > In past discussions two uses have been brought up: >> > >> > 1. if an 0-day is discovered which is exacerbated by a specific >> > privilege in user namespaces, that privilege could be turned off until a >> > reboot with a fixed kernel is scheduled, without fully disabling all >> > containers. >> > >> > 2. some systems may be specifically designed to run software which >> > only requires a few capabilities in a userns. In that case all others >> > could be disabled. >> > >> >> 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 >> behavior of everything allowed. Then, document the semantics of the >> whitelist in terms of inheritance etc., as a feature of user namespaces, >> not as a "type" of user namespace. > > The problem with making them inheritable is that an adversarial user > can just create a user namespace at boot that sits and waits for an > 0day to be published, then log in and attach to that namespace later, > since it has already inherited the open whitelist. > > It feels like there must be some other approach that doesn't feel as... > band-aid-y as this does, but I'm not sure what. We had a long discussion thread about this approach in the past and many of these points have been discussed there. Serge is to the point in terms of both the points (0-day issue as well as sandbox environment). At this moment we are exposed to those threats and apart from this patch-set I'm not aware of anything that handles it. Of course there are other alternatives that block user-ns creation altogether but blocking user-ns is not a real solution that works in every use-case. I'm open other ideas (if any) that do not block creation of user-ns, but lack of those will keep the 0-day issue lingering especially for environments where 'user-ns creation' is used heavily. 'Controlled-user-ns' jargon is within the kernel-space and is not exposed to the users (we don't have any API to do that), but I used those terms to explain within the kernel-community what this patch-set is trying to do. The user-application does not need nor need to know any of these changes as such. However, this additional knob gives admin an ability to control their behavior in those two circumstances. The default behavior that chose in this patch-set is so that it doesn't cause regression to anyone whatever is their use case is but now admin can set whatever default behavior they wish in the boot-scripts to suite their needs. Thanks, --mahesh.. -- 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
