Re: [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot

[Colin Walters]

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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/