Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF

[Eric Paris]

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-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/