On Thu, 2012-01-12 at 14:08 -0500, Kyle Moffett wrote: > On Thu, Jan 12, 2012 at 13:44, Andrew Lutomirski <luto@xxxxxxx> wrote: > > On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > >> You can do any amount of crazy things with selinux, but the other side > >> of the coin is that it would also be trivial to teach selinux about > >> this same "restricted environment" bit, and just say that a process > >> with that bit set doesn't get to match whatever selinux privilege > >> escalation rules.. > I don't see any issues with SELinux support for this feature. > > Specifically, when you try to execute something in SELinux, it will > first look at the types and try to "execute" (involving a type > transition IE: security label change). > > But if that fails in many cases it may still be allowed to > "execute_no_trans" (IE: regular non-privileged exec() without a > transition). That's not true. See specifically security/selinux/hooks.c::selinux_bprm_set_creds() We calculate a label for the new task (that may or may not be the same) and then check if there is permission to run the new binary with the new label. There is no fallback. The exception would be if the binary is on a MNT_NOSUID mount point, in which case we calculate the new label, then just revert to the same label. At first glance it looks to me like a reasonable way to implement this at first would be to do the new checks right next to any place we already do MNT_NOSUID checks and mimic their behavior. If there are other priv escalation points in the kernel we might need to consider if MNT_NOSUID is adequate.... -Eric -- 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
