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

From: Andy Lutomirski
Date: Sat Jan 14 2012 - 11:05:32 EST


On Sat, Jan 14, 2012 at 7:17 AM, Eric Paris <eparis@xxxxxxxxxx> wrote:
> -----Original Message-----
> From: Jamie Lokier [jamie@xxxxxxxxxxxxx]

> Andy Lutomirski wrote:
>
>> Is the current exec_no_trans check enough for you?  With my patch,
>> selinux can already block the execve if it wants.  (The policy is the
>> same as it would be if a program explicitly asked to run the new
>> executable with an unchanged security context.)  I'd be happy to fail
>> the exec in AppArmor, and then maybe AppArmor will change its mind
>> if/when users get annoyed :)
>
> Does SELinux block if userspace does exec entirely in userspace using
> mmap() and not execve()?  If not, why is execve() allowed to be different?
>
> Yes, we do (or can, and usually do in policy)
>

By blocking open, read, mmap, or mprotect? And, more to the point, why?

I've always found it weird/annoying that selinux blocks things that
can neither be used to gain privilege nor to DoS the system.
Certainly a fully confined selinux program can emulate the execution
of anything it can read -- it just might be slow.

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