Messages in this thread | | | Subject | Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs | From | Eric Paris <> | Date | Fri, 13 Jan 2012 15:13:25 -0500 |
| |
On Fri, 2012-01-13 at 11:45 -0800, Linus Torvalds wrote: > On Fri, Jan 13, 2012 at 11:39 AM, Andy Lutomirski <luto@amacapital.net> 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...
| |