Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve fromgranting privs

From: Eric Paris
Date: Fri Jan 13 2012 - 15:14:59 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/