Execmem boolean

Execmem boolean

[Ivan Gyurdiev]

Something needs to be done about the allow_execmem boolean - 
the default strict policy configuration on Fedora disables it,
which causes X not to work out of the box under strict policy. 
I think this is highly undesirable.

Should allow_execmem be enabled by default?

I know Stephen was asking about more fine-grained control
over allow_execmem and allow_execmod.

How can we combine those two requirements to come up with
a better solution?

Perhaps have allow_execmem turned on by default,
and then and-ed with per application booleans, we can
turn it off for selected applications?

The opposite approach (off by default, turn on
per application) doesn't work quite so well, beause
then you have per application booleans not respecting
the value of a global allow_execmem...

Or, we could get rid of allow_execmem completely, and
have only per application booleans...

--------

P.S. Please remove the gift port from types/network.te,
because otherwise the gift domain won't compile - this port is 
restricted to gift.te.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Execmem boolean

[Ivan Gyurdiev]

> 
> P.S. Please remove the gift port from types/network.te,
> because otherwise the gift domain won't compile - this port is 
> restricted to gift.te.

Never mind this, it's a configuration problem - my gift.te is not
properly updating.  (although there's really no reason for that 
port to be in network.te).

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Execmem boolean

[Stephen Smalley]

On Sun, 2005-06-26 at 17:42 -0400, Ivan Gyurdiev wrote:
> Something needs to be done about the allow_execmem boolean - 
> the default strict policy configuration on Fedora disables it,
> which causes X not to work out of the box under strict policy. 
> I think this is highly undesirable.
> 
> Should allow_execmem be enabled by default?
> 
> I know Stephen was asking about more fine-grained control
> over allow_execmem and allow_execmod.
> 
> How can we combine those two requirements to come up with
> a better solution?
> 
> Perhaps have allow_execmem turned on by default,
> and then and-ed with per application booleans, we can
> turn it off for selected applications?
> 
> The opposite approach (off by default, turn on
> per application) doesn't work quite so well, beause
> then you have per application booleans not respecting
> the value of a global allow_execmem...
> 
> Or, we could get rid of allow_execmem completely, and
> have only per application booleans...

Yes, I'm not sure how much value the global allow_execmem/allow_execmod
booleans provide.  In particular, since execmod should be limited to
specific file types (although the targeted policy presently violates
this), it isn't clear that you need a boolean there at all.  I'd say
that only execmod to types other than texrel_shlib_t truly require a
boolean.  execmem for the user domains (and all the associated programs
that run in them) is more problematic.

Note also that the execstack/execheap permission checks are now upstream
and should soon be in the FC devel kernel, so they will also begin to
have an impact.  execmem is the more general control (make any anonymous
mapping executable); execstack is a specific case (make the primary
process stack executable).  Programs that need to generate code at
runtime will require execmem but should not require execstack.  Programs
that require an executable stack will require both permissions.  No
program should legitimately require execheap, but it will take time to
fix them, starting with X module loader.

Also note that the legacy binary rules in the current policy are partly
obsoleted by the checkreqprot change that went into 2.6.12, so that
unless you are overriding the default checkreqprot value, SELinux is
only checking the protection requested by the application, so read
requests should no longer show up as read|execute to SELinux.  This
should eliminate the need for allowing execute to various file types
that are only mapped with read access by the application itself.

-- 
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: Execmem boolean

[Daniel J Walsh]

Stephen Smalley wrote:

>On Sun, 2005-06-26 at 17:42 -0400, Ivan Gyurdiev wrote:
>  
>
>>Something needs to be done about the allow_execmem boolean - 
>>the default strict policy configuration on Fedora disables it,
>>which causes X not to work out of the box under strict policy. 
>>I think this is highly undesirable.
>>
>>Should allow_execmem be enabled by default?
>>
>>I know Stephen was asking about more fine-grained control
>>over allow_execmem and allow_execmod.
>>
>>How can we combine those two requirements to come up with
>>a better solution?
>>
>>Perhaps have allow_execmem turned on by default,
>>and then and-ed with per application booleans, we can
>>turn it off for selected applications?
>>
>>The opposite approach (off by default, turn on
>>per application) doesn't work quite so well, beause
>>then you have per application booleans not respecting
>>the value of a global allow_execmem...
>>
>>Or, we could get rid of allow_execmem completely, and
>>have only per application booleans...
>>    
>>
>
>Yes, I'm not sure how much value the global allow_execmem/allow_execmod
>booleans provide.  In particular, since execmod should be limited to
>specific file types (although the targeted policy presently violates
>this), it isn't clear that you need a boolean there at all.  I'd say
>that only execmod to types other than texrel_shlib_t truly require a
>boolean.  execmem for the user domains (and all the associated programs
>that run in them) is more problematic.
>
>  
>
Problem is with third party apps,  They don't get labeled texrel_shlib_t 
and therefore do not work.

allow execmod allows them to work with the shlib_t label.  We can change 
this to a targeted vs strict.

>Note also that the execstack/execheap permission checks are now upstream
>and should soon be in the FC devel kernel, so they will also begin to
>have an impact.  execmem is the more general control (make any anonymous
>mapping executable); execstack is a specific case (make the primary
>process stack executable).  Programs that need to generate code at
>runtime will require execmem but should not require execstack.  Programs
>that require an executable stack will require both permissions.  No
>program should legitimately require execheap, but it will take time to
>fix them, starting with X module loader.
>  
>
Did these get added as default allow?  If policy is 19 or less?  Deny if 
policy > 19?

I don't think we should add any more access checks without bumping the 
policy version and putting
that logic in.



>Also note that the legacy binary rules in the current policy are partly
>obsoleted by the checkreqprot change that went into 2.6.12, so that
>unless you are overriding the default checkreqprot value, SELinux is
>only checking the protection requested by the application, so read
>requests should no longer show up as read|execute to SELinux.  This
>should eliminate the need for allowing execute to various file types
>that are only mapped with read access by the application itself.
>
>  
>


-- 



--
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: Execmem boolean

[Stephen Smalley]

On Wed, 2005-06-29 at 13:33 -0400, Daniel J Walsh wrote:
> Problem is with third party apps,  They don't get labeled texrel_shlib_t 
> and therefore do not work.
> 
> allow execmod allows them to work with the shlib_t label.  We can change 
> this to a targeted vs strict.

IMHO, we can allow execmod to texrel_shlib_t without requiring a boolean
around it at all.  Only case where I would care to shut off execmod is
for anything not explicitly labeled texrel_shlib_t, as that label
already indicates an explicit decision to allow text relocation on that
file.  Hence, we can keep wider execmod access (e.g. to shlib_t,
home_type, file_type, whatever) restricted via allow_execmod, and just
always include execmod to texrel_shlib_t.  Strict policy likely
shouldn't allow execmod to anything but texrel_shlib_t, and can thus
omit the boolean altogether.

> Did these get added as default allow?  If policy is 19 or less?  Deny if 
> policy > 19?
> 
> I don't think we should add any more access checks without bumping the 
> policy version and putting
> that logic in.

Well, they are already in 2.6.13-rc1, and no, they are not tied to a
particular policy version.  I think FC4 targeted policy already allows
them for unconfined domains.

-- 
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: Execmem boolean

[Ivan Gyurdiev]

>  Strict policy likely
> shouldn't allow execmod to anything but texrel_shlib_t, and can thus
> omit the boolean altogether.

Please don't break strict policy :(

I still have some hope left to be able to 
run it on my home machine. The level of "strictness"
should be configurable.

We could kill the allow_execmod/allow_execmem booleans,
allow execmod to texrel, allow exemem for X,
and then have per app booleans for other things we don't trust
(like Java applets?). 





--
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: Execmem boolean

[Stephen Smalley]

On Wed, 2005-06-29 at 14:54 -0400, Ivan Gyurdiev wrote:
> Please don't break strict policy :(
> 
> I still have some hope left to be able to 
> run it on my home machine. The level of "strictness"
> should be configurable.
> 
> We could kill the allow_execmod/allow_execmem booleans,
> allow execmod to texrel, allow exemem for X,
> and then have per app booleans for other things we don't trust
> (like Java applets?). 

You'd also need something to enable/disable execmem for the user
domains, as not everything that wants it runs in its own domain yet.

-- 
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: Execmem boolean

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>> Strict policy likely
>>shouldn't allow execmod to anything but texrel_shlib_t, and can thus
>>omit the boolean altogether.
>>    
>>
>
>Please don't break strict policy :(
>
>I still have some hope left to be able to 
>run it on my home machine. The level of "strictness"
>should be configurable.
>
>  
>
>We could kill the allow_execmod/allow_execmem booleans,
>allow execmod to texrel, allow exemem for X,
>  
>
Ok.
Should be a boolean allow_X_execmem.  Most people don't need execmem for 
X.  (Only nvidia binary drivers)

>and then have per app booleans for other things we don't trust
>(like Java applets?). 
>
>
>
>
>  
>


-- 



--
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: Execmem boolean

[Stephen Smalley]

On Wed, 2005-06-29 at 15:37 -0400, Daniel J Walsh wrote:
> Ok.
> Should be a boolean allow_X_execmem.  Most people don't need execmem for 
> X.  (Only nvidia binary drivers)

I've seen it with other (open source) drivers too.

-- 
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: Execmem boolean

[Ivan Gyurdiev]

> Ok.
> Should be a boolean allow_X_execmem.  Most people don't need execmem for 
> X.  (Only nvidia binary drivers)

Are you sure? I thought it was always needed...
I recall bringing this up in the first place, because I ran into
this problem at work (where I don't use Nvidia binary modules).

I've had execmem enabled forever on my home computer.

I can recheck...



--
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.