lkml.org 
[lkml]   [2018]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCHv3 0/2] capability controlled user-namespaces
    On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
    > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
    >> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
    >> > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
    >> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
    >> >> > Quoting James Morris (james.l.morris@oracle.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.
    >
    Yes, but that's a conflict of trusted operations (that requires
    SYS_ADMIN) and untrusted processes it may spawn.

    >> 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.

    \
     
     \ /
      Last update: 2018-01-14 23:18    [W:4.602 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site