Interesting reading on exec* access checks.

Interesting reading on exec* access checks.

[Daniel J Walsh]

http://people.redhat.com/drepper/selinux-mem.html

We are planning on turning off allow_execmem, allow_execmod, 
allow_execheap for unconfined_t in targeted policy.  We are working to 
clean up any problems this might cause.  This will add additional 
security features to Userspace, but might cause headaches.

If you have the latest policy installed on Rawhide

selinux-policy-targeted-2.1.0-3 or later you can try it out by running

setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0

You might need to relabel /usr/lib and /lib.

Any help would be appreciated.  :^)

-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interesting reading on exec* access checks.

[Stephen Smalley]

On Thu, 2005-12-08 at 16:29 -0500, Daniel J Walsh wrote:
> http://people.redhat.com/drepper/selinux-mem.html

The description of execmem says:
"The solution for the anonymous case is to create the memory region
without execution permission and then, when the wanted content is
created, change the permission to include PROT_EXEC but not PROT_WRITE."

But this will still trigger an execmem check, as the check is applied
upon mmap or mprotect for anonymous mappings with PROT_EXEC,
irrespective of PROT_WRITE, in order to control the ability to execute
arbitrary memory (not just to control the ability to execute currently
writable memory).  In the case of private file mappings, it is handled
differently, with execmem only applied upon mmap or mprotect with
PROT_EXEC and PROT_WRITE simultaneously, and execmod applied upon
PROT_EXEC by itself after a prior modification.

> We are planning on turning off allow_execmem, allow_execmod, 
> allow_execheap for unconfined_t in targeted policy.  We are working to 
> clean up any problems this might cause.  This will add additional 
> security features to Userspace, but might cause headaches.
> 
> If you have the latest policy installed on Rawhide
> 
> selinux-policy-targeted-2.1.0-3 or later you can try it out by running
> 
> setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0

There is no allow_execheap, but there is an allow_execstack.  Note that
turning off allow_execmem should also disable execstack; execmem covers
a superset of what execstack covers.  If you need runtime code
generation, you can enable execmem while disabling execstack to retain
protection of the stack while permitting generation of code to other
anonymous memory.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interesting reading on exec* access checks.

[Yuichi Nakamura]

Daniel J Walsh wrote:
> http://people.redhat.com/drepper/selinux-mem.html
I have basic question about these permissions.
Fedora Core already have "Exec Shield" to prevent execution of malicious code on memory.
I can not understand relationship between exec shield and these permissions.
What is good point of these permissions?
In other words, 
I would like to know 
"Attack that can not be prevented  by exec shield, 
 but can be prevented by these permissions(exec* permissions)".

Does anyone know ?

Yuichi Nakamura



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interesting reading on exec* access checks.

[Stephen Smalley]

On Mon, 2005-12-12 at 12:03 -0500, Yuichi Nakamura wrote:
> Daniel J Walsh wrote:
> > http://people.redhat.com/drepper/selinux-mem.html
> I have basic question about these permissions.
> Fedora Core already have "Exec Shield" to prevent execution of malicious code on memory.
> I can not understand relationship between exec shield and these permissions.
> What is good point of these permissions?
> In other words, 
> I would like to know 
> "Attack that can not be prevented  by exec shield, 
>  but can be prevented by these permissions(exec* permissions)".
> 
> Does anyone know ?

exec-shield is a mechanism that approximates NX support, but does not
define policy, so it cannot differentiate between a legitimate
application request for executable memory from the same request induced
by malicious code.  The SELinux exec* checks provide a way to apply
policy control over what processes can mmap/mprotect memory with
PROT_EXEC.  With just exec-shield, you lack protection against explicit
PROT_EXEC mmap/mprotect requests induced by malicious code; with just
SELinux exec* checking, you lack a mechanism to enforce NX (unless you
have hardware NX support), so the SELinux checking by itself is not very
useful.  exec-shield by itself provides some useful protection; coupled
with the SELinux checks, you get stronger protection.  Example of the
difference in paxtest output (with dummy function moved to outer scope)
before and after turning of the SELinux booleans for exec*:

 Executable data                          : Killed
 Executable heap                          : Killed
 Executable stack                         : Killed
-Executable anonymous mapping (mprotect)  : Vulnerable
-Executable bss (mprotect)                : Vulnerable
-Executable data (mprotect)               : Vulnerable
-Executable heap (mprotect)               : Vulnerable
-Executable shared library bss (mprotect) : Vulnerable
-Executable shared library data (mprotect): Vulnerable
-Executable stack (mprotect)              : Vulnerable
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Executable stack (mprotect)              : Killed
<snip>
-Writable text segments                   : Vulnerable
+Writable text segments                   : Killed

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.