On Fri, 2012-01-13 at 11:45 -0800, Linus Torvalds wrote: > On Fri, Jan 13, 2012 at 11:39 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > > Is the current exec_no_trans check enough for you? With my patch, > > selinux can already block the execve if it wants. > > If this feature has "selinux can do xyz if it wants", it is broken. > > The *whole* point is to get the f*^%ing crazy "security managers can > do xyz" things away from it. > > The flag - when set - should give a 100% guarantee that security > context doesn't change, and an operation that would change it would > error out. That's what you would get today following the MNT_NOSUID example. SELinux just has the additional property that the policy can either error (and fail the exec) or allow no selinux transition to happen. > Not a "selinux can block it if it wants". None of that "wants" crap. > None of the "you can configure security rules to do xyz" crap. > > One simple rule: no security changes from the context that set the flag. > > Any other rule will inevitably cause random gray areas where some > random security manager does something stupid. We have enough of those > already. No more. So you can't drop capabilities(7)? If you come in with permission you can't get rid of it? Ouch. My thought on expanding the SELinux support beyond 'no transition' (which I suggest we do today) would be that we might allow SELinux transitions if we can show the the 'child' domain is a subset of the 'parent' domain. Much the same as I imagine you can still drop capabilities after setting this flag you might be able to drop SELinux permissions, but that's something that would need a lot of thought and that we don't have a good way to do today... -- 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
