[lkml]   [2012]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot
    On Mon, Jan 16, 2012 at 12:49 PM, Colin Walters <> wrote:
    > On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote:
    >> To make the no_new_privs discussion more concrete, here is an updated
    >> series that is actually useful.  It adds PR_SET_NO_NEW_PRIVS
    > I think it'd be clearer to call it PR_SET_NOSUID - basically it should
    > match the semantics for MS_NOSUID mounts, as if on every exec()
    > thereafter the target binary was on a nosuid filesystem.

    The MS_NOSUID semantics are somewhat ridiculous for selinux, and I'd
    rather not make them match for no_new_privs. AppArmor completely
    ignores MS_NOSUID, so I think the rename would just cause more

    > You might then change this flag to only take effect on a later exec(),
    > which would solve your race condition for the hypothetical PAM module.

    That would just make it more complicated. The race is already solved
    in the current patch, anyway.

    >>  with the
    >> same semantics as before (plus John Johansen's AppArmor fix and with
    >> improved bisectability).  It then allows some unshare flags
    > What's the rationale behind the unshare subset?  Did you actually
    > analyze any setuid binaries found on Debian/Fedora etc. and determined
    > that e.g. CLONE_NEWNET was problematic for some reason?

    CLONE_NEWNET seems more likely to consume significant kernel resources
    than the others. I didn't have a great reason, though. Unsharing the
    filesystem namespace is possibly dangerous because it could prevent an
    unmount in the original namespace from taking effect everywhere.

    > I actually want CLONE_NEWNET for my build tool, so I can be sure the
    > arbitrary code I'm executing as part of the build at least isn't
    > downloading more new code.

    Fair enough. I may add this in v3. seccomp is an even better
    solution, though :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-01-16 22:29    [W:0.021 / U:9.052 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site