On Sun, Jan 15, 2012 at 4:37 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 with the > same semantics as before (plus John Johansen's AppArmor fix and with > improved bisectability). It then allows some unshare flags and chroot > (sometimes) when no_new_privs is set. Here's another reason to allow setuid/setresuid when no_new_privs is set: I'd like a pam_no_new_privs module that lets me set no_new_privs for certain highly untrusted users. The way to do it is: PR_SET_NO_NEW_PRIVS setuid(uid) execve(the user's shell) If setuid were disallowed, it would have to be: setuid(uid) PR_SET_NO_NEW_PRIVS execve(the user's shell) The latter is racy: the user can log in once, then log in a second time and ptrace the login or sshd process between setuid and PR_SET_NO_NEW_PRIVS. --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
