Policy infrastructure problems and improvement

Policy infrastructure problems and improvement

[James Carter]

I am looking at improving the policy infrastructure.  The ultimate goal
is to make SELinux policy writing, policy customization, policy
management, and administration easier and less confusing. My focus will
be on the userspace parts of SELinux. 

My plan to do this is as follows:
(1) Determine and enumerate the existing problems of the current
infrastructure.
(2) Determine the desired capabilities and architecture of the ideal
infrastructure.
(3) Determine the changes needed to the current architecture to fix the
current problems and to provide the desired capabilities.
(4) Make the policy infrastructure as close to the ideal as possible
while providing some kind of backwards compatibility and taking other
practicalities into consideration.

I have had some informal discussions with others internally and at
Tresys, and the five emails to follow have my summary of the problems
that have been identified in those discussions.

My hope is that there will be a good discussion and that others on the
list will identify other problems and provide more details or examples
to the problems already identified.

-- 
James Carter <jwcart2@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: Policy infrastructure problems and improvement

[Casey Schaufler]

James Carter wrote:
> I am looking at improving the policy infrastructure.  The ultimate goal
> is to make SELinux policy writing, policy customization, policy
> management, and administration easier and less confusing. My focus will
> be on the userspace parts of SELinux. 
>
> My plan to do this is as follows:
> (1) Determine and enumerate the existing problems of the current
> infrastructure.
> (2) Determine the desired capabilities and architecture of the ideal
> infrastructure.
> (3) Determine the changes needed to the current architecture to fix the
> current problems and to provide the desired capabilities.
> (4) Make the policy infrastructure as close to the ideal as possible
> while providing some kind of backwards compatibility and taking other
> practicalities into consideration.
>
> I have had some informal discussions with others internally and at
> Tresys, and the five emails to follow have my summary of the problems
> that have been identified in those discussions.
>
> My hope is that there will be a good discussion and that others on the
> list will identify other problems and provide more details or examples
> to the problems already identified.
>   

I will throw my traditional comment on the pile as I didn't see that
you had it on your list anywhere. The policy required to describe a
system is too large.

Thank you.



--
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: Policy infrastructure problems and improvement

[James Carter]

On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
> James Carter wrote:
> > I am looking at improving the policy infrastructure.  The ultimate goal
> > is to make SELinux policy writing, policy customization, policy
> > management, and administration easier and less confusing. My focus will
> > be on the userspace parts of SELinux. 
> >
> > My plan to do this is as follows:
> > (1) Determine and enumerate the existing problems of the current
> > infrastructure.
> > (2) Determine the desired capabilities and architecture of the ideal
> > infrastructure.
> > (3) Determine the changes needed to the current architecture to fix the
> > current problems and to provide the desired capabilities.
> > (4) Make the policy infrastructure as close to the ideal as possible
> > while providing some kind of backwards compatibility and taking other
> > practicalities into consideration.
> >
> > I have had some informal discussions with others internally and at
> > Tresys, and the five emails to follow have my summary of the problems
> > that have been identified in those discussions.
> >
> > My hope is that there will be a good discussion and that others on the
> > list will identify other problems and provide more details or examples
> > to the problems already identified.
> >   
> 
> I will throw my traditional comment on the pile as I didn't see that
> you had it on your list anywhere. The policy required to describe a
> system is too large.
> 

That's easy to fix.  Make the system smaller. ;)

I think that this would fit under complexity of SElinux policies.

Again, better layering is needed.  It would be nice if I could just
write policy for the particular domains and resources that I cared about
without having to worry about the policy for the rest of the system.
Unfortunately, policy writing differs from program writing in that while
different programs that run on a system *share* resources and so it
doesn't matter what the other programs do (for the most part) as long as
my program gets to use those resources at some point, all of the
policies work together to *control* resources.  In the end, you must
have one policy.  The question is how to write the policies in a more
layered way and have the policy infrastructure merge the layers
together.  

> Thank you.
> 
> 
> 
> --
> 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.
-- 
James Carter <jwcart2@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: Policy infrastructure problems and improvement

[Alexey S]

On Thu, Apr 09, 2009 at 11:28:03AM -0400, James Carter wrote:
> I am looking at improving the policy infrastructure.  The ultimate goal
> is to make SELinux policy writing, policy customization, policy
> management, and administration easier and less confusing. My focus will
> be on the userspace parts of SELinux. 
> 
> My plan to do this is as follows:
> (1) Determine and enumerate the existing problems of the current
> infrastructure.
> (2) Determine the desired capabilities and architecture of the ideal
> infrastructure.
> (3) Determine the changes needed to the current architecture to fix the
> current problems and to provide the desired capabilities.
> (4) Make the policy infrastructure as close to the ideal as possible
> while providing some kind of backwards compatibility and taking other
> practicalities into consideration.
> 
> I have had some informal discussions with others internally and at
> Tresys, and the five emails to follow have my summary of the problems
> that have been identified in those discussions.
> 
> My hope is that there will be a good discussion and that others on the
> list will identify other problems and provide more details or examples
> to the problems already identified.

May I put my 5cents?
It would be great if mapping of domain attributes to numbers be preserved
somewhere during linking/expanding of modules into binary policy.
And if libqpol-based tools would be able to use that mapping when displaying
their results.
Otherwise it is too confusing to see @ttr0121 instead of domain_type during policy
analysis, especially when numbers change after module (re|un|)load.

PS: Could binary policy have 'debug' segments, that are not loaded into kernel,
but persist in a file?
PPS: Have I missed something somewhere? It is so obviously inconvenient, so
I don't believe it's only me requesting this thing.

Thanks.
-- 
Alexey S.

--
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: Policy infrastructure problems and improvement

[Stephen Smalley]

On Fri, 2009-04-10 at 17:43 +0500, Alexey S wrote:
> On Thu, Apr 09, 2009 at 11:28:03AM -0400, James Carter wrote:
> > I am looking at improving the policy infrastructure.  The ultimate goal
> > is to make SELinux policy writing, policy customization, policy
> > management, and administration easier and less confusing. My focus will
> > be on the userspace parts of SELinux. 
> > 
> > My plan to do this is as follows:
> > (1) Determine and enumerate the existing problems of the current
> > infrastructure.
> > (2) Determine the desired capabilities and architecture of the ideal
> > infrastructure.
> > (3) Determine the changes needed to the current architecture to fix the
> > current problems and to provide the desired capabilities.
> > (4) Make the policy infrastructure as close to the ideal as possible
> > while providing some kind of backwards compatibility and taking other
> > practicalities into consideration.
> > 
> > I have had some informal discussions with others internally and at
> > Tresys, and the five emails to follow have my summary of the problems
> > that have been identified in those discussions.
> > 
> > My hope is that there will be a good discussion and that others on the
> > list will identify other problems and provide more details or examples
> > to the problems already identified.
> 
> May I put my 5cents?
> It would be great if mapping of domain attributes to numbers be preserved
> somewhere during linking/expanding of modules into binary policy.
> And if libqpol-based tools would be able to use that mapping when displaying
> their results.
> Otherwise it is too confusing to see @ttr0121 instead of domain_type during policy
> analysis, especially when numbers change after module (re|un|)load.

policy.24 already makes this change (preservation of attribute names in
the types symtab in the final kernel policy).

You can however already see the attribute names with policy < 24 by
running apol and friends on the modular policy rather than the final
kernel policy.

> PS: Could binary policy have 'debug' segments, that are not loaded into kernel,
> but persist in a file?
> PPS: Have I missed something somewhere? It is so obviously inconvenient, so
> I don't believe it's only me requesting this thing.

-- 
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: Policy infrastructure problems and improvement

[Xavier Toth]

On Thu, Apr 9, 2009 at 3:28 PM, James Carter <jwcart2@tycho.nsa.gov> wrote:
> I am looking at improving the policy infrastructure.  The ultimate goal
> is to make SELinux policy writing, policy customization, policy
> management, and administration easier and less confusing. My focus will
> be on the userspace parts of SELinux.
>
> My plan to do this is as follows:
> (1) Determine and enumerate the existing problems of the current
> infrastructure.
> (2) Determine the desired capabilities and architecture of the ideal
> infrastructure.
> (3) Determine the changes needed to the current architecture to fix the
> current problems and to provide the desired capabilities.
> (4) Make the policy infrastructure as close to the ideal as possible
> while providing some kind of backwards compatibility and taking other
> practicalities into consideration.
>
> I have had some informal discussions with others internally and at
> Tresys, and the five emails to follow have my summary of the problems
> that have been identified in those discussions.
>
> My hope is that there will be a good discussion and that others on the
> list will identify other problems and provide more details or examples
> to the problems already identified.
>
> --
> James Carter <jwcart2@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.
>

We need a policy debugger.

Ted


--
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: Policy infrastructure problems and improvement

[Joe Nall]

On Apr 10, 2009, at 7:45 AM, Stephen Smalley wrote:

> On Fri, 2009-04-10 at 17:43 +0500, Alexey S wrote:
>> On Thu, Apr 09, 2009 at 11:28:03AM -0400, James Carter wrote:
>>> I am looking at improving the policy infrastructure.  The ultimate  
>>> goal
>>> is to make SELinux policy writing, policy customization, policy
>>> management, and administration easier and less confusing. My focus  
>>> will
>>> be on the userspace parts of SELinux.
>>>
>>> My plan to do this is as follows:
>>> (1) Determine and enumerate the existing problems of the current
>>> infrastructure.
>>> (2) Determine the desired capabilities and architecture of the ideal
>>> infrastructure.
>>> (3) Determine the changes needed to the current architecture to  
>>> fix the
>>> current problems and to provide the desired capabilities.
>>> (4) Make the policy infrastructure as close to the ideal as possible
>>> while providing some kind of backwards compatibility and taking  
>>> other
>>> practicalities into consideration.
>>>
>>> I have had some informal discussions with others internally and at
>>> Tresys, and the five emails to follow have my summary of the  
>>> problems
>>> that have been identified in those discussions.
>>>
>>> My hope is that there will be a good discussion and that others on  
>>> the
>>> list will identify other problems and provide more details or  
>>> examples
>>> to the problems already identified.
>>
>> May I put my 5cents?
>> It would be great if mapping of domain attributes to numbers be  
>> preserved
>> somewhere during linking/expanding of modules into binary policy.
>> And if libqpol-based tools would be able to use that mapping when  
>> displaying
>> their results.
>> Otherwise it is too confusing to see @ttr0121 instead of  
>> domain_type during policy
>> analysis, especially when numbers change after module (re|un|)load.
>
> policy.24 already makes this change (preservation of attribute names  
> in
> the types symtab in the final kernel policy).
>
> You can however already see the attribute names with policy < 24 by
> running apol and friends on the modular policy rather than the final
> kernel policy.

like this

seinfo -x -t$1 /etc/selinux/mls/modules/active/base.pp /etc/selinux/ 
mls/modules/active/modules/*pp

This can be very slow (hours) - all in the reading of the pp files.  
Replace $1 and mls as appropriate.

joe

>
>> PS: Could binary policy have 'debug' segments, that are not loaded  
>> into kernel,
>> but persist in a file?
>> PPS: Have I missed something somewhere? It is so obviously  
>> inconvenient, so
>> I don't believe it's only me requesting this thing.
>
> -- 
> 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.


--
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: Policy infrastructure problems and improvement

[Joe Nall]

On Apr 10, 2009, at 7:34 AM, James Carter wrote:

> On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
>> James Carter wrote:
>>> I am looking at improving the policy infrastructure.  The ultimate  
>>> goal
>>> is to make SELinux policy writing, policy customization, policy
>>> management, and administration easier and less confusing. My focus  
>>> will
>>> be on the userspace parts of SELinux.
>>>
>>> My plan to do this is as follows:
>>> (1) Determine and enumerate the existing problems of the current
>>> infrastructure.
>>> (2) Determine the desired capabilities and architecture of the ideal
>>> infrastructure.
>>> (3) Determine the changes needed to the current architecture to  
>>> fix the
>>> current problems and to provide the desired capabilities.
>>> (4) Make the policy infrastructure as close to the ideal as possible
>>> while providing some kind of backwards compatibility and taking  
>>> other
>>> practicalities into consideration.
>>>
>>> I have had some informal discussions with others internally and at
>>> Tresys, and the five emails to follow have my summary of the  
>>> problems
>>> that have been identified in those discussions.
>>>
>>> My hope is that there will be a good discussion and that others on  
>>> the
>>> list will identify other problems and provide more details or  
>>> examples
>>> to the problems already identified.
>>>
>>
>> I will throw my traditional comment on the pile as I didn't see that
>> you had it on your list anywhere. The policy required to describe a
>> system is too large.
>>
>
> That's easy to fix.  Make the system smaller. ;)
>
> I think that this would fit under complexity of SElinux policies.
>
> Again, better layering is needed.  It would be nice if I could just
> write policy for the particular domains and resources that I cared  
> about
> without having to worry about the policy for the rest of the system.
> Unfortunately, policy writing differs from program writing in that  
> while
> different programs that run on a system *share* resources and so it
> doesn't matter what the other programs do (for the most part) as  
> long as
> my program gets to use those resources at some point, all of the
> policies work together to *control* resources.  In the end, you must
> have one policy.  The question is how to write the policies in a more
> layered way and have the policy infrastructure merge the layers
> together.

audit2allow needs to understand your layers of abstraction or they  
won't be very useful. I've watched a number of developers in our group  
stall at the audit2allow policy writing level and never really get the  
need to understand the system macros and the 'why' of it all.

Some of these same developers never get that some avcs are inevitable  
and blithely grant privilege until they don't have any avcs - granting  
user_t enormous new privs along the way. We use seinfo to look for  
attribute diffs and source inspection, but we need better command line  
tools to look for these issues in an automated way.

If Chris and Dan maintained and distributed policy as modules and not  
as monolithic entities, the impetus and understanding to improve the  
tool chain would be much stronger.

joe


>
>> Thank you.
>>
>>
>>
>> --
>> 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.
> -- 
> James Carter <jwcart2@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.


--
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: Policy infrastructure problems and improvement

[James Carter]

On Fri, 2009-04-10 at 09:51 -0500, Joe Nall wrote:
> On Apr 10, 2009, at 7:34 AM, James Carter wrote:
> 
> > On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
> >> James Carter wrote:
> >>> I am looking at improving the policy infrastructure.  The ultimate  
> >>> goal
> >>> is to make SELinux policy writing, policy customization, policy
> >>> management, and administration easier and less confusing. My focus  
> >>> will
> >>> be on the userspace parts of SELinux.
> >>>
> >>> My plan to do this is as follows:
> >>> (1) Determine and enumerate the existing problems of the current
> >>> infrastructure.
> >>> (2) Determine the desired capabilities and architecture of the ideal
> >>> infrastructure.
> >>> (3) Determine the changes needed to the current architecture to  
> >>> fix the
> >>> current problems and to provide the desired capabilities.
> >>> (4) Make the policy infrastructure as close to the ideal as possible
> >>> while providing some kind of backwards compatibility and taking  
> >>> other
> >>> practicalities into consideration.
> >>>
> >>> I have had some informal discussions with others internally and at
> >>> Tresys, and the five emails to follow have my summary of the  
> >>> problems
> >>> that have been identified in those discussions.
> >>>
> >>> My hope is that there will be a good discussion and that others on  
> >>> the
> >>> list will identify other problems and provide more details or  
> >>> examples
> >>> to the problems already identified.
> >>>
> >>
> >> I will throw my traditional comment on the pile as I didn't see that
> >> you had it on your list anywhere. The policy required to describe a
> >> system is too large.
> >>
> >
> > That's easy to fix.  Make the system smaller. ;)
> >
> > I think that this would fit under complexity of SElinux policies.
> >
> > Again, better layering is needed.  It would be nice if I could just
> > write policy for the particular domains and resources that I cared  
> > about
> > without having to worry about the policy for the rest of the system.
> > Unfortunately, policy writing differs from program writing in that  
> > while
> > different programs that run on a system *share* resources and so it
> > doesn't matter what the other programs do (for the most part) as  
> > long as
> > my program gets to use those resources at some point, all of the
> > policies work together to *control* resources.  In the end, you must
> > have one policy.  The question is how to write the policies in a more
> > layered way and have the policy infrastructure merge the layers
> > together.
> 
> audit2allow needs to understand your layers of abstraction or they  
> won't be very useful. I've watched a number of developers in our group  
> stall at the audit2allow policy writing level and never really get the  
> need to understand the system macros and the 'why' of it all.
> 

Yes, it is desirable to have denials mapped back to the higher-level
language or layer that is being used, rather than to have to work with
the raw, low-level information.  Not any easy problem to solve, though.

> Some of these same developers never get that some avcs are inevitable  
> and blithely grant privilege until they don't have any avcs - granting  
> user_t enormous new privs along the way. We use seinfo to look for  
> attribute diffs and source inspection, but we need better command line  
> tools to look for these issues in an automated way.
> 
One goal is to make it easier to hook tools into the policy toolchain.

> If Chris and Dan maintained and distributed policy as modules and not  
> as monolithic entities, the impetus and understanding to improve the  
> tool chain would be much stronger.
> 
I am not sure I understand what you mean here.  Do you mean that if
Chris and Dan only maintained a part of the policy, while others
maintained the rest, the difficulty in putting all the parts together
would provide strong motivation to improve the toolchain?  That may be
true, but it would make for a miserable existence for Chris and Dan.

> joe
> 
> 
> >
> >> Thank you.
> >>
> >>
> >>
> >> --
> >> 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.
> > -- 
> > James Carter <jwcart2@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.
> 
> 
> --
> 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.
-- 
James Carter <jwcart2@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: Policy infrastructure problems and improvement

[Joe Nall]

On Apr 10, 2009, at 11:33 AM, James Carter wrote:

> On Fri, 2009-04-10 at 09:51 -0500, Joe Nall wrote:

...

>> If Chris and Dan maintained and distributed policy as modules and not
>> as monolithic entities, the impetus and understanding to improve the
>> tool chain would be much stronger.
>>
> I am not sure I understand what you mean here.  Do you mean that if
> Chris and Dan only maintained a part of the policy, while others
> maintained the rest,

no

> the difficulty in putting all the parts together
> would provide strong motivation to improve the toolchain?

yes

>  That may be
> true, but it would make for a miserable existence for Chris and Dan.

Perhaps. They are smart guys, I suspect we would all benefit from  
their cleverness in avoiding the misery.

We have 118 (out of 402) different application rpms with policy in  
them. I'm experiencing the pain already :)

joe

--
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: Policy infrastructure problems and improvement

[Casey Schaufler]

James Carter wrote:
> On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
>   
>> James Carter wrote:
>>     
>>> I am looking at improving the policy infrastructure.  The ultimate goal
>>> is to make SELinux policy writing, policy customization, policy
>>> management, and administration easier and less confusing. My focus will
>>> be on the userspace parts of SELinux. 
>>>
>>> My plan to do this is as follows:
>>> (1) Determine and enumerate the existing problems of the current
>>> infrastructure.
>>> (2) Determine the desired capabilities and architecture of the ideal
>>> infrastructure.
>>> (3) Determine the changes needed to the current architecture to fix the
>>> current problems and to provide the desired capabilities.
>>> (4) Make the policy infrastructure as close to the ideal as possible
>>> while providing some kind of backwards compatibility and taking other
>>> practicalities into consideration.
>>>
>>> I have had some informal discussions with others internally and at
>>> Tresys, and the five emails to follow have my summary of the problems
>>> that have been identified in those discussions.
>>>
>>> My hope is that there will be a good discussion and that others on the
>>> list will identify other problems and provide more details or examples
>>> to the problems already identified.
>>>   
>>>       
>> I will throw my traditional comment on the pile as I didn't see that
>> you had it on your list anywhere. The policy required to describe a
>> system is too large.
>>
>>     
>
> That's easy to fix.  Make the system smaller. ;)
>   

Or kick off all those stoopid users, if that's easier (smiley here).

> I think that this would fit under complexity of SElinux policies.
>   

Perhaps.

> Again, better layering is needed.  

Here I disagree. Obscuring the size behind layers or modularity
does not actually make it smaller.

> It would be nice if I could just
> write policy for the particular domains and resources that I cared about
> without having to worry about the policy for the rest of the system.
>   

The fact that you are willing to accept the behavior of "policy you
don't care about" also does not make the policy smaller.


> Unfortunately, policy writing differs from program writing in that while
> different programs that run on a system *share* resources and so it
> doesn't matter what the other programs do (for the most part) as long as
> my program gets to use those resources at some point, all of the
> policies work together to *control* resources.  In the end, you must
> have one policy.  

Yes. Interdependencies. That is why, in this context, size matters.

> The question is how to write the policies in a more
> layered way and have the policy infrastructure merge the layers
> together.  
>   

Ignoring the bulk of the policy and attending to a part of the policy
also does not make the rest of the policy go away. Because the SELinux
implementation is so granular you can't layer without losing value.

But that could just be me. It may be time for a grain of salt.

Thank you.


--
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: Policy infrastructure problems and improvement

[Alexey S]

On Fri, Apr 10, 2009 at 08:45:06AM -0400, Stephen Smalley wrote:
> On Fri, 2009-04-10 at 17:43 +0500, Alexey S wrote:
> > ...
> > And if libqpol-based tools would be able to use that mapping when displaying
> > their results.
> > Otherwise it is too confusing to see @ttr0121 instead of domain_type during policy
> > analysis, especially when numbers change after module (re|un|)load.
> 
> policy.24 already makes this change (preservation of attribute names in
> the types symtab in the final kernel policy).
Great! I really missed that thing. I have ever tried to hack policy compiler to
write the attributes mapping to the stderr...

> 
> You can however already see the attribute names with policy < 24 by
> running apol and friends on the modular policy rather than the final
> kernel policy.
There are some use-cases where there is no modules on the local machine.
And thus the policy is not "managed". And still it is not complete and needs
some analysing/understanding.
By the way, is it impossible to add some cryptographics signature to the binary policy
(and perhaps to the modules)? I would like to block REloading of policies without proper
signature (btw, it is very useful in the mentioned use-cases). I think it is some
infrastructure piece that is missing too.



-- 
Alexey S

--
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: Policy infrastructure problems and improvement

[Alexey S.]

On Fri, Apr 10, 2009 at 09:51:46AM -0500, Joe Nall wrote:
>
> On Apr 10, 2009, at 7:34 AM, James Carter wrote:
>
>> On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
>>
>> That's easy to fix.  Make the system smaller. ;)
>>
>> I think that this would fit under complexity of SElinux policies.
>>
>> Again, better layering is needed.  It would be nice if I could just
>> write policy for the particular domains and resources that I cared  
>> about
>> without having to worry about the policy for the rest of the system.
>> Unfortunately, policy writing differs from program writing in that  
>> while
>> different programs that run on a system *share* resources and so it
>> doesn't matter what the other programs do (for the most part) as long 
>> as
>> my program gets to use those resources at some point, all of the
>> policies work together to *control* resources.  In the end, you must
>> have one policy.  The question is how to write the policies in a more
>> layered way and have the policy infrastructure merge the layers
>> together.
>
> audit2allow needs to understand your layers of abstraction or they won't 
> be very useful. I've watched a number of developers in our group stall at 
> the audit2allow policy writing level and never really get the need to 
> understand the system macros and the 'why' of it all.
>
> Some of these same developers never get that some avcs are inevitable  
> and blithely grant privilege until they don't have any avcs - granting  
> user_t enormous new privs along the way. We use seinfo to look for  
> attribute diffs and source inspection, but we need better command line  
> tools to look for these issues in an automated way.

Me as policy developer will benefit a lot if there will be a tool, that
maps m4 macros to allows/denials and allows/denials back to m4 macros.
The only thing that is available to me now is 'grep -r', but it does not help
always.
I would like a system, that will answer my questions like:
 'What macros can be used to generate these "allows"?' (sorted by the level of invocation)
 'What macro generate this denies and where it is invoked from?' (sorted the same way)
 'How the permissions of the domain will be affected if I add/throw out this macro?' (in current context)
Well, there is some tool, that does that. It is called human memory and experience.
But sometimes that fails. And it takes a lot of time to (re)gather that experience.

PS: Maybe have I missed something again? That tools will be so much useful.

--
Alexey S.

--
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: Policy infrastructure problems and improvement

[Daniel J Walsh]

On 04/13/2009 03:28 AM, Alexey S. wrote:
> On Fri, Apr 10, 2009 at 09:51:46AM -0500, Joe Nall wrote:
>> On Apr 10, 2009, at 7:34 AM, James Carter wrote:
>>
>>> On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
>>>
>>> That's easy to fix.  Make the system smaller. ;)
>>>
>>> I think that this would fit under complexity of SElinux policies.
>>>
>>> Again, better layering is needed.  It would be nice if I could just
>>> write policy for the particular domains and resources that I cared
>>> about
>>> without having to worry about the policy for the rest of the system.
>>> Unfortunately, policy writing differs from program writing in that
>>> while
>>> different programs that run on a system *share* resources and so it
>>> doesn't matter what the other programs do (for the most part) as long
>>> as
>>> my program gets to use those resources at some point, all of the
>>> policies work together to *control* resources.  In the end, you must
>>> have one policy.  The question is how to write the policies in a more
>>> layered way and have the policy infrastructure merge the layers
>>> together.
>> audit2allow needs to understand your layers of abstraction or they won't
>> be very useful. I've watched a number of developers in our group stall at
>> the audit2allow policy writing level and never really get the need to
>> understand the system macros and the 'why' of it all.
>>
>> Some of these same developers never get that some avcs are inevitable
>> and blithely grant privilege until they don't have any avcs - granting
>> user_t enormous new privs along the way. We use seinfo to look for
>> attribute diffs and source inspection, but we need better command line
>> tools to look for these issues in an automated way.
>
> Me as policy developer will benefit a lot if there will be a tool, that
> maps m4 macros to allows/denials and allows/denials back to m4 macros.
> The only thing that is available to me now is 'grep -r', but it does not help
> always.
> I would like a system, that will answer my questions like:
>   'What macros can be used to generate these "allows"?' (sorted by the level of invocation)
>   'What macro generate this denies and where it is invoked from?' (sorted the same way)
>   'How the permissions of the domain will be affected if I add/throw out this macro?' (in current context)
> Well, there is some tool, that does that. It is called human memory and experience.
> But sometimes that fails. And it takes a lot of time to (re)gather that experience.
>
> PS: Maybe have I missed something again? That tools will be so much useful.
>
sepolgen is supposed to do this, but it needs some tender loving care.

audit2allow -R

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


--
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: Policy infrastructure problems and improvement

[James Carter]

On Fri, 2009-04-10 at 19:45 -0700, Casey Schaufler wrote:
> James Carter wrote:
> > On Thu, 2009-04-09 at 21:19 -0700, Casey Schaufler wrote:
> >   
> >> James Carter wrote:
> >>     
> >>> I am looking at improving the policy infrastructure.  The ultimate goal
> >>> is to make SELinux policy writing, policy customization, policy
> >>> management, and administration easier and less confusing. My focus will
> >>> be on the userspace parts of SELinux. 
> >>>
> >>> My plan to do this is as follows:
> >>> (1) Determine and enumerate the existing problems of the current
> >>> infrastructure.
> >>> (2) Determine the desired capabilities and architecture of the ideal
> >>> infrastructure.
> >>> (3) Determine the changes needed to the current architecture to fix the
> >>> current problems and to provide the desired capabilities.
> >>> (4) Make the policy infrastructure as close to the ideal as possible
> >>> while providing some kind of backwards compatibility and taking other
> >>> practicalities into consideration.
> >>>
> >>> I have had some informal discussions with others internally and at
> >>> Tresys, and the five emails to follow have my summary of the problems
> >>> that have been identified in those discussions.
> >>>
> >>> My hope is that there will be a good discussion and that others on the
> >>> list will identify other problems and provide more details or examples
> >>> to the problems already identified.
> >>>   
> >>>       
> >> I will throw my traditional comment on the pile as I didn't see that
> >> you had it on your list anywhere. The policy required to describe a
> >> system is too large.
> >>
> >>     
> >
> > That's easy to fix.  Make the system smaller. ;)
> >   
> 
> Or kick off all those stoopid users, if that's easier (smiley here).
> 
> > I think that this would fit under complexity of SElinux policies.
> >   
> 
> Perhaps.
> 
> > Again, better layering is needed.  
> 
> Here I disagree. Obscuring the size behind layers or modularity
> does not actually make it smaller.
> 
> > It would be nice if I could just
> > write policy for the particular domains and resources that I cared about
> > without having to worry about the policy for the rest of the system.
> >   
> 
> The fact that you are willing to accept the behavior of "policy you
> don't care about" also does not make the policy smaller.
> 
The size of the policy is not the main issue.  Yes, the policy can be
large, and in some systems that can be an issue.  But the concern here
is the complexity of the policy and how to reduce that complexity.
> 
> > Unfortunately, policy writing differs from program writing in that while
> > different programs that run on a system *share* resources and so it
> > doesn't matter what the other programs do (for the most part) as long as
> > my program gets to use those resources at some point, all of the
> > policies work together to *control* resources.  In the end, you must
> > have one policy.  
> 
> Yes. Interdependencies. That is why, in this context, size matters.
> 
> > The question is how to write the policies in a more
> > layered way and have the policy infrastructure merge the layers
> > together.  
> >   
> 
> Ignoring the bulk of the policy and attending to a part of the policy
> also does not make the rest of the policy go away. Because the SELinux
> implementation is so granular you can't layer without losing value.
> 
True, it doesn't make it go away, just like writing a program in a
higher level language does not make all of the low level instructions go
away.  But it does allow the programmer to just focus on the task at
hand, without worrying about all of the low level details.

Likewise, if there were a layer of policy that secured the base system,
so that the policy writer could just focus on the policy for the desired
workflow of the system, that would greatly reduce the complexity of the
policy that he would have to deal with.

It may be that this is not possible, you may be right that to layer like
this would require a low level policy that was too permissive to be of
any value, but I am not that pessimistic yet.

> But that could just be me. It may be time for a grain of salt.
> 
> Thank you.
-- 
James Carter <jwcart2@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.