lkml.org 
[lkml]   [2012]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 30/43] userns: Fail exec for suid and sgid binaries with ids outside our user namespace.
    "Serge E. Hallyn" <serge@hallyn.com> writes:

    > Quoting Eric W. Beiderman (ebiederm@xmission.com):
    >> From: Eric W. Biederman <ebiederm@xmission.com>
    >>
    >
    > Oh, perhaps this is the right place in the thread to discuss the issue of
    > what to do with file capabilities? I'm ok waiting until the next iteration
    > to even discuss it, so long as we start by refusing setting of fcaps by
    > any task not in init_user_ns.

    For now we do refuse all callers in the init_user_ns because that path
    is protected by a capable and not an ns_capable call.

    And as a general policy I have pushed all of the changes from capable to
    ns_capable out till after we get these other user namespace bits so we
    can get the patches reviewed so hopefully don't enable something that is
    not safe.

    Let's just note here that when we ever get a filesystem mounted in
    something other than the init_user_ns or otherwise allow file
    capabilities that do not belong to the init_user_ns we need to an
    additional exec check to avoid a security issue for processes in the
    init_user_ns using those credentials.

    The other direction the init_user_ns setting file caps on a file and use
    using them in a child namespace seems safe, and practical because of the
    way we handle capabilities. Aka if you have a capability in an outer
    user namespace you also have it in a child user namespace. Which means
    a file cap exec today will give you just the capabilities in the child
    user namespace.

    Something else to think about when we reach filesystems mounted in
    different user namespaces (aka unprivileged mounts) are security
    labels on files in different user namespaces. Not any kind of immediate
    concern but something we may have to handle eventually.

    Eric


    \
     
     \ /
      Last update: 2012-04-24 04:29    [W:0.047 / U:29.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site