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.  :^)

--

[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

[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

[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

[Mike Hearn]

On Mon, 12 Dec 2005 12:27:07 -0500, Stephen Smalley wrote:
>  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 
I thought that in order to get malicious code into a running program with
any degree of reliability you need to know its VMA layout, and execshield
prevents that. So how can you do attacks like this with execshield enabled?

thanks -mike

[Steve G]

> So how can you do attacks like this with execshield enabled? 
I think the core idea is to have layers of protection so that if there ever was a
hole discovered in exec-shield, you still have another layer of defense. There's
at least 3 layers that I can see for people with local access: execshield, SE
Linux, and the gcc/glibc FORTIFY_SOURCE & stack protector options.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Stephen Smalley]

On Tue, 2005-12-13 at 17:03 +0000, Mike Hearn wrote:
>  On Mon, 12 Dec 2005 12:27:07 -0500, Stephen Smalley wrote:
>  > 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
>  
>  I thought that in order to get malicious code into a running program with
>  any degree of reliability you need to know its VMA layout, and execshield
>  prevents that. So how can you do attacks like this with execshield enabled? 
http://www.stanford.edu/~blp/papers/asrandom.pdf

-- 
Stephen Smalley
National Security Agency

[Mike Hearn]

On Tue, 13 Dec 2005 13:37:22 -0500, Stephen Smalley wrote:
> > I thought that in order to get malicious code into a running
> program with
> > any degree of reliability you need to know its VMA layout, and execshield
> > prevents that. So how can you do attacks like this with execshield enabled?
>  
>  http://www.stanford.edu/~blp/papers/asrandom.pdf 
Interesting paper, thanks. I guess that answers my question pretty well.

It's nice to know it's still (mostly) effective on 64 bit systems though.

thanks -mike