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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
