lkml.org 
[lkml]   [2012]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
On Sat, Jan 14, 2012 at 7:17 AM, Eric Paris <eparis@redhat.com> wrote:
> -----Original Message-----
> From: Jamie Lokier [jamie@shareable.org]

> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-01-14 17:07    [W:0.059 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site