wish-list item for selinux policy analyss

wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

dear selinux people,

on my wish-list for selinux is a means to tell, at runtime,
which avc messages have been utilised.  not when - if.

the equivalent of code coverage analysis tools.

i envisage this to be implemented - hand-waving - by a single
bit which is marked in the in-kernel-memory store of selinux avc
policy, for reasons of minimising impact on run-time performance
(i believe that tying something into the avc audit logging
system, would be too slow).

the reason for this is to be able to fire up a system, run
it for a while (live) say oh a few months, and then determine
which bits of the selinux policy.conf have never ever actually
been used.

track them down, and remove them from the selinux source policy.

... via analysis of the policy.conf, back to the macros from
whence they came.

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: wish-list item for selinux policy analyss

[Ivan Gyurdiev]

>  reason for this is to be able to fire up a system, run
> it for a while (live) say oh a few months, and then determine
> which bits of the selinux policy.conf have never ever actually
> been used.

I see several problems with this idea:

1) Usage frequency does not necessarily correlate to
whether the rule is valid or not - you'd have to test
every code path to establish whether the rule is needed or not.
I find this to be better accomplished with comments in policy
before every group of rules (and _not_ using audit2allow).

2) It's not clear that policy source should fit as well as possible to
program usage patterns. Those patterns can change, and I think
it's a good idea to leave some room for such changes - policy usually
permits the program to do more than it actually does, and I think
that's okay, as long as nothing dangerous is allowed. 

3) Another reason for (2) is that policy source is reduced 
to a number of primitives (macros) that you work with. Some of
those macros couple functionality that doesn't always go
together, but usually does - generic macros). The result
is permissions you don't need. However, that's not necessarily
a problem - it allows the policy writer to overlook certain
things, and focus on more important concerns. 



--
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: wish-list item for selinux policy analyss

[Casey Schaufler]

--- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:

> >  reason for this is to be able to fire up a
> system, run
> > it for a while (live) say oh a few months, and
> then determine
> > which bits of the selinux policy.conf have never
> ever actually
> > been used.
> 
> I see several problems with this idea:

I say amen to points 1-3. I add ...

4) A derived policy set will only tell you
what the programs do, not what they are
intended to do. Should I leave doors
unlocked because burglers attempt
to use them? If no burgler tries my
door for a year does that mean having
a lock on my door is unnecessary?




Casey Schaufler
casey@schaufler-ca.com

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

--
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: wish-list item for selinux policy analyss

[Ron Kuris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Casey Schaufler wrote:

| I say amen to points 1-3. I add ...
|
| 4) A derived policy set will only tell you what the programs do,
| not what they are intended to do. Should I leave doors unlocked
| because burglers attempt to use them? If no burgler tries my door
| for a year does that mean having a lock on my door is unnecessary?

I think the logic here is backwards.  If nobody is using that door for
a year, then that door is a candidate for becoming a wall instead of a
door.  Otherwise, you end up in a maze of twisty passages, where
nobody knows what doors are needed and why.  Fewer doors means less
memory also, which can be important for embedded systems.

I think this wish-list item doesn't tell you what you can remove from
a policy.  However, it might tell you which rules are candidates to be
changed to a "deny" rule (or lack of an "allow" rule really).  Lets
say a particular program used to create temp files but they don't any
more.  Chances are, the rule will stay around, unless you realize it
isn't getting used any more, in which case you might want to
investigate it.

I do the same thing with iptables.  I have rules for services/ports
that have counters.  If the counters are zero, I look at the service
and decide whether or not I still need that service any more.

Ron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwtx/VkC/44kdyuYRAre/AKDlOMgNkc5M790lbwWM3sT7M9UCrgCg264u
Om80p6tVIIr77yhxpXj7mnw=
=MBlJ
-----END PGP SIGNATURE-----



--
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 10:38:08AM -0700, Ron Kuris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Casey Schaufler wrote:
> 
> | I say amen to points 1-3. I add ...
> |
> | 4) A derived policy set will only tell you what the programs do,
> | not what they are intended to do. Should I leave doors unlocked
> | because burglers attempt to use them? If no burgler tries my door
> | for a year does that mean having a lock on my door is unnecessary?
> 
> I think the logic here is backwards.  

 yep.  selinux is "MAC".

> a year, then that door is a candidate for becoming a wall instead of a
> door.  Otherwise, you end up in a maze of twisty passages, where
> nobody knows what doors are needed and why.  Fewer doors means less
> memory also, which can be important for embedded systems.
> 
> I think this wish-list item doesn't tell you what you can remove from
> a policy.  However, it might tell you which rules are candidates to be
> changed to a "deny" rule (or lack of an "allow" rule really).  

 absolutely.

 that was the intent.


--
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: wish-list item for selinux policy analyss

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> > I think the logic here is backwards.  
> 
>  yep.  selinux is "MAC".

Damn, and here I was, thinking it was "CAM" all along.
No wonder I'm so confused.




Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 


--
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 06:04:43PM -0700, Casey Schaufler wrote:
> 
> 
> --- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> 
> > > I think the logic here is backwards.  
> > 
> >  yep.  selinux is "MAC".
> 
> Damn, and here I was, thinking it was "CAM" all along.

 hey, content addressable memory would help enormously here
 because you could use an policy lookup algorithm that would
 on a non-parallelised system be much less efficient yada yada.


--
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 09:56:58AM -0700, Casey Schaufler wrote:
> 
> 
> --- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:
> 
> > >  reason for this is to be able to fire up a
> > system, run
> > > it for a while (live) say oh a few months, and
> > then determine
> > > which bits of the selinux policy.conf have never
> > ever actually
> > > been used.
> > 
> > I see several problems with this idea:
> 
> I say amen to points 1-3. I add ...
> 
> 4) A derived policy set will only tell you
> what the programs do, not what they are
> intended to do. Should I leave doors
> unlocked because burglers attempt
> to use them? If no burgler tries my
> door for a year does that mean having
> a lock on my door is unnecessary?
 
 wrong way round, casey.

 intent of wish-list item is to be able to say "this door
 hasn't been used for a year, let's brick it up".

 not, as you imply, "this door hasn't been tried at all in a year, let's
 now leave it wide open".

 l.

--
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: wish-list item for selinux policy analyss

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Wed, Jun 29, 2005 at 09:56:58AM -0700, Casey
> Schaufler wrote:
> > 
> > 
> > --- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:
> > 
> > > >  reason for this is to be able to fire up a
> > > system, run
> > > > it for a while (live) say oh a few months, and
> > > then determine
> > > > which bits of the selinux policy.conf have
> never
> > > ever actually
> > > > been used.
> > > 
> > > I see several problems with this idea:
> > 
> > I say amen to points 1-3. I add ...
> > 
> > 4) A derived policy set will only tell you
> > what the programs do, not what they are
> > intended to do. Should I leave doors
> > unlocked because burglers attempt
> > to use them? If no burgler tries my
> > door for a year does that mean having
> > a lock on my door is unnecessary?
>  
>  wrong way round, casey.
> 
>  intent of wish-list item is to be able to say "this
> door
>  hasn't been used for a year, let's brick it up".
> 
>  not, as you imply, "this door hasn't been tried at
> all in a year, let's
>  now leave it wide open".

I get it now. My brain was still in the
context of reducing the size of the
policy, and I may have made a
connection that wasn't really there.
If the goal is to reduce the policy
size you might use this method
to find rules you can remove, and
that could be denial rules, which
would be what I objected too.

Never mind.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 06:10:09PM -0700, Casey Schaufler wrote:
> >  wrong way round, casey.
> > 
> >  intent of wish-list item is to be able to say "this
> > door
> >  hasn't been used for a year, let's brick it up".

> I get it now. My brain was still in the
> context of reducing the size of the
> policy, 

 this could help - albeit not as much as ... okay,
 separate-message-to-list-time, i have an idea.

> and I may have made a
> connection that wasn't really there.

> If the goal is to reduce the policy
> size you might use this method
> to find rules you can remove, 

 yes.

> and
> that could be denial rules, which
> would be what I objected too.

 ah :)


--
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 11:27:12AM -0400, Ivan Gyurdiev wrote:
> >  reason for this is to be able to fire up a system, run
> > it for a while (live) say oh a few months, and then determine
> > which bits of the selinux policy.conf have never ever actually
> > been used.
> 
> I see several problems with this idea:
> 
> 1) Usage frequency does not necessarily correlate to
> whether the rule is valid or not - you'd have to test
> every code path to establish whether the rule is needed or not.

 yes.

 this i would deem to be acceptable.

 after say six months of running a system live, i believe
 it reasonable for an admin to conclude that after such a period of time
 (they may choose a more or less acceptable period of time) that any
 rules not in use by then ain't gonna be needed.

 for that PARTICULAR config / usage pattern.

 of course, if the box requires additional packages / changes in
 requirements, the criteria changes / usage patterns change.


> I find this to be better accomplished with comments in policy
> before every group of rules (and _not_ using audit2allow).
> 
> 2) It's not clear that policy source should fit as well as possible to
> program usage patterns. Those patterns can change, and I think
> it's a good idea to leave some room for such changes - policy usually
> permits the program to do more than it actually does, and I think
> that's okay, as long as nothing dangerous is allowed. 

 i am a little fried right now to explain why i believe that is
 not a good argument, but i believe that if you look carefully
 at what you have said, you are saying "i think allowing more
 than is necessary is okay, therefore i don't think we should
 tools to people who _might_ want to go a little further / make
 a more restrictive policy because we want it to be _difficult_
 for them to disagree with us and diverge from policy source
 as controlled by us."

 if i have mistaken the intent of your statement, please
 accept my apologies for the above interpretation of what you
 have said.
 
 l.

 

--
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: wish-list item for selinux policy analyss

[Ivan Gyurdiev]

> > 2) It's not clear that policy source should fit as well as possible to
> > program usage patterns. Those patterns can change, and I think
> > it's a good idea to leave some room for such changes - policy usually
> > permits the program to do more than it actually does, and I think
> > that's okay, as long as nothing dangerous is allowed. 
> 
>  i am a little fried right now to explain why i believe that is
>  not a good argument, but i believe that if you look carefully
>  at what you have said, you are saying "i think allowing more
>  than is necessary is okay, therefore i don't think we should
>  tools to people who _might_ want to go a little further / make
>  a more restrictive policy because we want it to be _difficult_
>  for them to disagree with us and diverge from policy source
>  as controlled by us."

No, actually, what I was saying is that I don't believe such a 
tool (as described) would be very helpful to me at tracking down 
policy bit rot. I feel that taking out rules written by someone 
else, based on my particular usage patterns is the wrong way to 
go... though I've done it before, because there was no way to 
figure out what those rules try to do, and why they were there
(people didn't comment policy).

If I'm the app developer, I should know why the rules are in 
there. If I'm the policy developer, I should comment my policy 
to accomplish that, and to allow other policy writers to contribute,
and maintain policy.  If I'm the end user, I probably shouldn't 
be taking important rules out of the policy without consideration 
of the policy writer's intent, and expect it not to break.

This is just my personal opinion - it has nothing to do with
the company I work for, or some grand conspiracy to maintain
control of the policy (no such thing exists, since it is open
source). I don't understand why you need an internal kernel 
change to do what you like, however - what's wrong with working 
on top of the audit log? Just comment out all the rules you're
interested in, and look for denials?


--
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: wish-list item for selinux policy analyss

[Stephen Smalley]

On Thu, 2005-06-30 at 03:05 -0400, Ivan Gyurdiev wrote:
> I don't understand why you need an internal kernel 
> change to do what you like, however - what's wrong with working 
> on top of the audit log? Just comment out all the rules you're
> interested in, and look for denials?

Or just add auditallow rules and let it audit all grantings for a while,
then reduce your rule set accordingly.

-- 
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: wish-list item for selinux policy analyss

[Luke Kenneth Casson Leighton]

On Thu, Jun 30, 2005 at 03:05:56AM -0400, Ivan Gyurdiev wrote:
 
> This is just my personal opinion - it has nothing to do with
> the company I work for, or some grand conspiracy to maintain
> control of the policy (no such thing exists, since it is open
> source). I don't understand why you need an internal kernel 
> change to do what you like, however - what's wrong with working 
> on top of the audit log? Just comment out all the rules you're
> interested in, and look for denials?
 
 hiya ivan,

 yes, joshua described something which would achieve the same thing
 using audit logging.

 (thank you joshua!)

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: wish-list item for selinux policy analyss

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>dear selinux people,
>
>on my wish-list for selinux is a means to tell, at runtime,
>which avc messages have been utilised.  not when - if.
>
>the equivalent of code coverage analysis tools.
>
>i envisage this to be implemented - hand-waving - by a single
>bit which is marked in the in-kernel-memory store of selinux avc
>policy, for reasons of minimising impact on run-time performance
>(i believe that tying something into the avc audit logging
>system, would be too slow).
>
>the reason for this is to be able to fire up a system, run
>it for a while (live) say oh a few months, and then determine
>which bits of the selinux policy.conf have never ever actually
>been used.
>
>track them down, and remove them from the selinux source policy.
>
>... via analysis of the policy.conf, back to the macros from
>whence they came.
>
>l
>  
>
Not that I think this is a good idea; many rules are only there for 
corner case situations or errors but if you really want to do it you 
don't even need a new tool, the existing ones will do just fine.

First add an auditallow * * for all object classes and permissions, then 
reload that policy
wait until you have the data you want (6 months should yield a few tb of 
logs)
grep granted /wherever/log | sed -e s/granted/denied/ | audit2allow > 
somefile
then sediff /etc/selinux/strict/policy/policy.18 somefile

you'll want to diff against the binary since the audit messages will be 
the equivalent of an expanded policy
Have fun, you'll probably get 100,000's of rules

you could use apol at this point to track down the rules in the 
policy.conf.. tracing back to the macro call that made it will be very 
challenging though

Joshua Brindle

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