[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, 2012-01-16 at 13:25 -0800, Andy Lutomirski wrote:

    > The MS_NOSUID semantics are somewhat ridiculous for selinux,

    I don't see how they're ridiculous.

    > and I'd
    > rather not make them match for no_new_privs.

    Note your patch for selinux does exactly the same thing in the NOSUID
    case and your NO_NEW_PRIVS flag. Right?

    - if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
    + if ((bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) ||
    + (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))
    new_tsec->sid = old_tsec->sid;

    > AppArmor completely
    > ignores MS_NOSUID,

    Ugh...well, I guess if it doesn't store any security data associated
    with files, only with file names, then there's nothing for it to do.
    Like I said before though, I think SELinux is the only sane LSM.

    > CLONE_NEWNET seems more likely to consume significant kernel resources
    > than the others.

    This actually brings up something we need to think about - if we're
    heading towards being able to do bind mounts as non-root (which is
    necessary for me) we'd need limits on e.g. the number of mounts that can
    be made for a given uid/cgroup.

    I have a picked-from-thin-air hardcoded limit of 50 in my setuid binary,
    but I just realized that that's 50*RLIMIT_NPROC which is kind of

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

    Hmmm...hadn't considered that either. So the issue here is if a server
    admin has e.g. a NFS mount and my build tool makes a new copy of the
    mount namespace, a process may still have it busy when she goes to
    unmount it?

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

    Yeah, definitely more flexible, though realistic use of seccomp depends
    on someone making a nice userspace tool to compile sets of syscalls like
    "no networking".

     \ /
      Last update: 2012-01-16 22:49    [W:0.045 / U:0.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site