Provide finer-grained booleans for execmem/execmod, please

Provide finer-grained booleans for execmem/execmod, please

[Stephen Smalley]

Hi,

I'd like to again request finer-grained booleans for execmem and
execmod, possibly nested within the existing coarse-grained boolean, so
that we can allow it as needed for X and similar programs while denying
it elsewhere.  To show why this is useful, below is the diff of paxtest
(with nested function moved to global scope) results on the latest FC3
kernel with SELinux permissive vs. enforcing with the allow_execmem and
allow_execmod booleans set to 0.  The permissive output shows what is
being provided by exec-shield w/o SELinux, while the enforcing output
shows what added benefit is provided by the SELinux execmem/execmod
controls when they are denied to the domain in question.  Note that in
this test, /proc/sys/kernel/exec-shield was 1 and paxtest was built via
make generic.

--- paxtest-permissive.log	2005-04-11 14:14:23.000000000 -0400
+++ paxtest-enforcing.log	2005-04-11 14:14:23.000000000 -0400
@@ -9,18 +9,18 @@
 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
 Anonymous mapping randomisation test     : 8 bits (guessed)
-Heap randomisation test (ET_EXEC)        : 14 bits (guessed)
-Heap randomisation test (ET_DYN)         : 12 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : No randomisation
 Main executable randomisation (ET_EXEC)  : No randomisation
-Main executable randomisation (ET_DYN)   : 12 bits (guessed)
+Main executable randomisation (ET_DYN)   : No randomisation
 Shared library randomisation test        : No randomisation
 Stack randomisation test (SEGMEXEC)      : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)      : 17 bits (guessed)
@@ -30,4 +30,4 @@
 Return to function (memcpy, RANDEXEC)    : Vulnerable
 Executable shared library bss            : Vulnerable
 Executable shared library data           : Vulnerable
-Writable text segments                   : Vulnerable
+Writable text segments                   : Killed

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Provide finer-grained booleans for execmem/execmod, please

[Daniel J Walsh]

Stephen Smalley wrote:

>Hi,
>
>I'd like to again request finer-grained booleans for execmem and
>execmod, possibly nested within the existing coarse-grained boolean, so
>that we can allow it as needed for X and similar programs while denying
>it elsewhere.  To show why this is useful, below is the diff of paxtest
>(with nested function moved to global scope) results on the latest FC3
>kernel with SELinux permissive vs. enforcing with the allow_execmem and
>allow_execmod booleans set to 0.  The permissive output shows what is
>being provided by exec-shield w/o SELinux, while the enforcing output
>shows what added benefit is provided by the SELinux execmem/execmod
>controls when they are denied to the domain in question.  Note that in
>this test, /proc/sys/kernel/exec-shield was 1 and paxtest was built via
>make generic.
>
>  
>
We can do that, the problem is we are having an explosion of booleans.  
I just don't want to
get to the point where every app that needs execmem has a boolean.  
Maybe we need two booleans
allow_trusted_execmem, allow_untrusted_execmem.  So ones that are 
explainable like Java and X
would be trusted and other random ones that we can not necessarily 
explain would be untrusted.

Dan

>--- paxtest-permissive.log	2005-04-11 14:14:23.000000000 -0400
>+++ paxtest-enforcing.log	2005-04-11 14:14:23.000000000 -0400
>@@ -9,18 +9,18 @@
> 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
> Anonymous mapping randomisation test     : 8 bits (guessed)
>-Heap randomisation test (ET_EXEC)        : 14 bits (guessed)
>-Heap randomisation test (ET_DYN)         : 12 bits (guessed)
>+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
>+Heap randomisation test (ET_DYN)         : No randomisation
> Main executable randomisation (ET_EXEC)  : No randomisation
>-Main executable randomisation (ET_DYN)   : 12 bits (guessed)
>+Main executable randomisation (ET_DYN)   : No randomisation
> Shared library randomisation test        : No randomisation
> Stack randomisation test (SEGMEXEC)      : 17 bits (guessed)
> Stack randomisation test (PAGEEXEC)      : 17 bits (guessed)
>@@ -30,4 +30,4 @@
> Return to function (memcpy, RANDEXEC)    : Vulnerable
> Executable shared library bss            : Vulnerable
> Executable shared library data           : Vulnerable
>-Writable text segments                   : Vulnerable
>+Writable text segments                   : Killed
>
>  
>


-- 



--
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: Provide finer-grained booleans for execmem/execmod, please

[Stephen Smalley]

On Thu, 2005-04-14 at 09:51 -0400, Daniel J Walsh wrote:
> We can do that, the problem is we are having an explosion of booleans.  
> I just don't want to
> get to the point where every app that needs execmem has a boolean.  
> Maybe we need two booleans
> allow_trusted_execmem, allow_untrusted_execmem.  So ones that are 
> explainable like Java and X
> would be trusted and other random ones that we can not necessarily 
> explain would be untrusted.

I wouldn't classify java as "trusted", but I understand your meaning.
Likely want a separation for execmem between system programs like X,
udev and kudzu and user programs like java.  Possibly one per user
domain, so you can allow it to user_t but deny it for sysadm_t (or at
least separate booleans for unprivileged user domains vs. admin
domains).

execmod possibly doesn't require further booleans since it is already
tied to a particular shared library type (texrel_shlib_t), although if
you allow execmod to other types (e.g. shlib_t), that should likely be
covered by a boolean or limited to very specific domains.  

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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.