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