Problem with semodule mls policy

Problem with semodule mls policy

[Daniel J Walsh]

How do I get semodule to create policy.20 at SystemHigh and everything 
other files at SystemLow?


--
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: Problem with semodule mls policy

[Stephen Smalley]

On Wed, 2006-03-15 at 09:26 -0500, Daniel J Walsh wrote:
> How do I get semodule to create policy.20 at SystemHigh and everything 
> other files at SystemLow?

Options:
1) As with the devpts problem, if we had range_transitions for object
classes supported by checkpolicy and the kernel, then we could do this
via a range_transition rule, as policy.20 is created in a separate
directory.  Good idea for a kernel enhancement, not a short term option.
2) Modify libsemanage to explicitly set the context on the installed
files based on some configuration.  Using matchpathcon/file_contexts is
a potential concern for bootstrapping, although it can likely be worked
around.  Putting additional entries into semanage.conf, similar to the
existing entry for specifying the file-mode, would be another option.

-- 
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: Problem with semodule mls policy

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2006-03-15 at 09:26 -0500, Daniel J Walsh wrote:
>> How do I get semodule to create policy.20 at SystemHigh and everything 
>> other files at SystemLow?
> 
Why do we want policy.20 at SystemHigh again? The only scenerio I can 
think of is the user->role mappings but who will be using those rather 
than seuser mappings? For that matter, seuser file should probably be at 
SystemHigh...

> Options:
> 1) As with the devpts problem, if we had range_transitions for object
> classes supported by checkpolicy and the kernel, then we could do this
> via a range_transition rule, as policy.20 is created in a separate
> directory.  Good idea for a kernel enhancement, not a short term option.
> 2) Modify libsemanage to explicitly set the context on the installed
> files based on some configuration.  Using matchpathcon/file_contexts is
> a potential concern for bootstrapping, although it can likely be worked
> around.  Putting additional entries into semanage.conf, similar to the
> existing entry for specifying the file-mode, would be another option.
> 


--
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: Problem with semodule mls policy

[Stephen Smalley]

On Wed, 2006-03-15 at 11:01 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2006-03-15 at 09:26 -0500, Daniel J Walsh wrote:
> >> How do I get semodule to create policy.20 at SystemHigh and everything 
> >> other files at SystemLow?
> > 
> Why do we want policy.20 at SystemHigh again? The only scenerio I can 
> think of is the user->role mappings but who will be using those rather 
> than seuser mappings? For that matter, seuser file should probably be at 
> SystemHigh...

Possibly local customizations are in view here, e.g. the contents of
interfaces.local, that are then fed into the final policy.20 emitted by
libsemanage?  seusers is the more likely concern, as you note, and it is
harder to transparently label it separately since it doesn't live in its
own dedicated subdirectory (so range_transition wouldn't help with it;
you'd need libsemanage code modification).
 
-- 
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: Problem with semodule mls policy

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2006-03-15 at 11:01 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2006-03-15 at 09:26 -0500, Daniel J Walsh wrote:
>>>> How do I get semodule to create policy.20 at SystemHigh and everything 
>>>> other files at SystemLow?
>> Why do we want policy.20 at SystemHigh again? The only scenerio I can 
>> think of is the user->role mappings but who will be using those rather 
>> than seuser mappings? For that matter, seuser file should probably be at 
>> SystemHigh...
> 
> Possibly local customizations are in view here, e.g. the contents of
> interfaces.local, that are then fed into the final policy.20 emitted by
> libsemanage?  seusers is the more likely concern, as you note, and it is
> harder to transparently label it separately since it doesn't live in its
> own dedicated subdirectory (so range_transition wouldn't help with it;
> you'd need libsemanage code modification).
>  
The entire module store (/etc/selinux/<type>/modules/*) should be 
entirely inaccessible except by an semanage_t domain (and policy server 
later) via type enforcement, so those shouldn't be a concern. The 
policy.20 shouldn't really contain any sensitive information so I think 
the only necessary modification is to label seusers differently, correct?

--
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: Problem with semodule mls policy

[Stephen Smalley]

On Wed, 2006-03-15 at 11:37 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > Possibly local customizations are in view here, e.g. the contents of
> > interfaces.local, that are then fed into the final policy.20 emitted by
> > libsemanage?  seusers is the more likely concern, as you note, and it is
> > harder to transparently label it separately since it doesn't live in its
> > own dedicated subdirectory (so range_transition wouldn't help with it;
> > you'd need libsemanage code modification).
> >  
> The entire module store (/etc/selinux/<type>/modules/*) should be 
> entirely inaccessible except by an semanage_t domain (and policy server 
> later) via type enforcement, so those shouldn't be a concern. The 
> policy.20 shouldn't really contain any sensitive information so I think 
> the only necessary modification is to label seusers differently, correct?

I wasn't sure whether the fact that e.g. netif eth0 is assigned
SystemHigh and netif eth1 is assigned SystemLow in interfaces.local
(which is then compiled into policy.20) might be considered sensitive.
If so, that would make the final policy.20 sensitive as well.

-- 
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: Problem with semodule mls policy

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2006-03-15 at 11:37 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> Possibly local customizations are in view here, e.g. the contents of
>>> interfaces.local, that are then fed into the final policy.20 emitted by
>>> libsemanage?  seusers is the more likely concern, as you note, and it is
>>> harder to transparently label it separately since it doesn't live in its
>>> own dedicated subdirectory (so range_transition wouldn't help with it;
>>> you'd need libsemanage code modification).
>>>  
>> The entire module store (/etc/selinux/<type>/modules/*) should be 
>> entirely inaccessible except by an semanage_t domain (and policy server 
>> later) via type enforcement, so those shouldn't be a concern. The 
>> policy.20 shouldn't really contain any sensitive information so I think 
>> the only necessary modification is to label seusers differently, correct?
> 
> I wasn't sure whether the fact that e.g. netif eth0 is assigned
> SystemHigh and netif eth1 is assigned SystemLow in interfaces.local
> (which is then compiled into policy.20) might be considered sensitive.
> If so, that would make the final policy.20 sensitive as well.
> 

I can buy this, as well as nodecons having different levels. The strange 
thing is that you don't know what the levels are exactly, you just know 
their relationships to each other. ie: eth0 is s1 and eth1 is s5 so eth1 
is higher sensitivity even though I don't know what that sensitivity 
means. How big of an issue is this? Chad?

writing down files of different levels from within libsemanage means any 
libsemanage client must be mls trusted, which may or may not be an 
issue, I'm not sure.

So, if this is an issue then both seusers and policy.20 need to be 
labeled differently.. should this be done through libsemanage config or 
some appconfig in the policy?

--
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: Problem with semodule mls policy

[Stephen Smalley]

On Wed, 2006-03-15 at 13:00 -0500, Joshua Brindle wrote:
> I can buy this, as well as nodecons having different levels. The strange 
> thing is that you don't know what the levels are exactly, you just know 
> their relationships to each other. ie: eth0 is s1 and eth1 is s5 so eth1 
> is higher sensitivity even though I don't know what that sensitivity 
> means. How big of an issue is this? Chad?
> 
> writing down files of different levels from within libsemanage means any 
> libsemanage client must be mls trusted, which may or may not be an 
> issue, I'm not sure.
> 
> So, if this is an issue then both seusers and policy.20 need to be 
> labeled differently.. should this be done through libsemanage config or 
> some appconfig in the policy?

libsemanage could call matchpathcon and just use the returned context,
as long as we guarantee an initial installed file_contexts file for
bootstrapping.  semanage.conf is not an option I suppose since it now
lives directly in /etc/selinux and is policy-independent.  

-- 
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: Problem with semodule mls policy

[Daniel J Walsh]

Stephen Smalley wrote:
> On Wed, 2006-03-15 at 13:00 -0500, Joshua Brindle wrote:
>   
>> I can buy this, as well as nodecons having different levels. The strange 
>> thing is that you don't know what the levels are exactly, you just know 
>> their relationships to each other. ie: eth0 is s1 and eth1 is s5 so eth1 
>> is higher sensitivity even though I don't know what that sensitivity 
>> means. How big of an issue is this? Chad?
>>
>> writing down files of different levels from within libsemanage means any 
>> libsemanage client must be mls trusted, which may or may not be an 
>> issue, I'm not sure.
>>
>> So, if this is an issue then both seusers and policy.20 need to be 
>> labeled differently.. should this be done through libsemanage config or 
>> some appconfig in the policy?
>>     
>
> libsemanage could call matchpathcon and just use the returned context,
> as long as we guarantee an initial installed file_contexts file for
> bootstrapping.  semanage.conf is not an option I suppose since it now
> lives directly in /etc/selinux and is policy-independent.  
>
>   
If you don't have an initial file_contexts file at install time,  you 
are going to have a lot more problems than this.

--
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: Problem with semodule mls policy

[Chad Hanson]

Some comments inline below...

> -----Original Message-----
> From: Joshua Brindle [mailto:jbrindle@tresys.com]
> Sent: Wednesday, March 15, 2006 12:01 PM
> To: Stephen Smalley
> Cc: Daniel J Walsh; Christopher J. PeBenito; Russell Coker; SE Linux
> Subject: Re: Problem with semodule mls policy
>  
> >> The entire module store (/etc/selinux/<type>/modules/*) should be 
> >> entirely inaccessible except by an semanage_t domain (and 
> >> policy server later) via type enforcement, so those shouldn't be
> >> a concern. The policy.20 shouldn't really contain any sensitive 
> >> information so I think the only necessary modification is to 
> >> label seusers differently, correct?
> > 

Other than any range_transitions or any other rule definitions that would
call MLS labels directly I would agree. 

/etc/selinux/mls/contexts/files(/*) should be at SystemHigh since it is
basically a database of the on-disk configuration. 

> > I wasn't sure whether the fact that e.g. netif eth0 is assigned
> > SystemHigh and netif eth1 is assigned SystemLow in interfaces.local
> > (which is then compiled into policy.20) might be considered sensitive.
> > If so, that would make the final policy.20 sensitive as well.
> > 
> 
> I can buy this, as well as nodecons having different levels. The strange 
> thing is that you don't know what the levels are exactly, you just know 
> their relationships to each other. ie: eth0 is s1 and eth1 is s5 so eth1 
> is higher sensitivity even though I don't know what that sensitivity 
> means. How big of an issue is this? Chad?
> 

This information should be at SystemHigh since we are talking about levels.
I think IP addresses could possibly thought of in the same way.... So both
netif/nodecon rules should be protected.

> writing down files of different levels from within libsemanage means any 
> libsemanage client must be mls trusted, which may or may not be an 
> issue, I'm not sure.
> 
> So, if this is an issue then both seusers and policy.20 need to be 
> labeled differently.. should this be done through libsemanage config or 
> some appconfig in the policy?
> 

seusers should be at SystemHigh as well since it MLS labels inside of it. If
on MLS the seusers was purely just a user mapping and the real user labels
were in the policy, this wouldn't be an issue.

-Chad

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