On Mon, Jan 16, 2012 at 12:49 PM, Colin Walters <walters@xxxxxxxxxx> 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 confusion. > > 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 :) --Andy -- 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
