From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5T25fgA009134 for ; Tue, 28 Jun 2005 22:05:41 -0400 (EDT) Received: from free.hands.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5T24saC001461 for ; Wed, 29 Jun 2005 02:04:54 GMT Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by free.hands.com (Postfix) with ESMTP id 49375BF7A for ; Wed, 29 Jun 2005 03:04:53 +0100 (BST) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1DnS5F-0002gt-58 for selinux@tycho.nsa.gov; Wed, 29 Jun 2005 03:13:49 +0100 Date: Wed, 29 Jun 2005 03:13:49 +0100 From: Luke Kenneth Casson Leighton To: SE-Linux Subject: wish-list item for selinux policy analyss Message-ID: <20050629021349.GA10219@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. -- -- http://lkcl.net -- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5TFUPgA013175 for ; Wed, 29 Jun 2005 11:30:26 -0400 (EDT) Received: from mx1.redhat.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5TFSvdE002734 for ; Wed, 29 Jun 2005 15:28:57 GMT Subject: Re: wish-list item for selinux policy analyss From: Ivan Gyurdiev Reply-To: gyurdiev@redhat.com To: Luke Kenneth Casson Leighton Cc: SE-Linux In-Reply-To: <20050629021349.GA10219@lkcl.net> References: <20050629021349.GA10219@lkcl.net> Content-Type: text/plain Date: Wed, 29 Jun 2005 11:27:12 -0400 Message-Id: <1120058832.17121.38.camel@celtics.boston.redhat.com> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5TGw6gA013957 for ; Wed, 29 Jun 2005 12:58:06 -0400 (EDT) Received: from web31609.mail.mud.yahoo.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with SMTP id j5TGuadE009408 for ; Wed, 29 Jun 2005 16:56:36 GMT Message-ID: <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> Date: Wed, 29 Jun 2005 09:56:58 -0700 (PDT) From: Casey Schaufler Subject: Re: wish-list item for selinux policy analyss To: gyurdiev@redhat.com, Luke Kenneth Casson Leighton Cc: SE-Linux In-Reply-To: <1120058832.17121.38.camel@celtics.boston.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --- 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: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5THd5gA014454 for ; Wed, 29 Jun 2005 13:39:05 -0400 (EDT) Received: from mail37-res-R.bigfish.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5THcC79014195 for ; Wed, 29 Jun 2005 17:38:12 GMT Message-ID: <42C2DC80.8070904@unify.com> Date: Wed, 29 Jun 2005 10:38:08 -0700 From: Ron Kuris MIME-Version: 1.0 To: Casey Schaufler CC: gyurdiev@redhat.com, Luke Kenneth Casson Leighton , SE-Linux Subject: Re: wish-list item for selinux policy analyss References: <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> In-Reply-To: <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U0aRgA018107 for ; Wed, 29 Jun 2005 20:36:27 -0400 (EDT) Received: from free.hands.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5U0ZV79011126 for ; Thu, 30 Jun 2005 00:35:31 GMT Date: Thu, 30 Jun 2005 01:37:00 +0100 From: Luke Kenneth Casson Leighton To: Ivan Gyurdiev Cc: SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630003700.GB8415@lkcl.net> References: <20050629021349.GA10219@lkcl.net> <1120058832.17121.38.camel@celtics.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1120058832.17121.38.camel@celtics.boston.redhat.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U0vQgA018245 for ; Wed, 29 Jun 2005 20:57:27 -0400 (EDT) Received: from free.hands.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5U0trdE015151 for ; Thu, 30 Jun 2005 00:55:54 GMT Date: Thu, 30 Jun 2005 02:05:26 +0100 From: Luke Kenneth Casson Leighton To: Ron Kuris Cc: Casey Schaufler , gyurdiev@redhat.com, SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630010526.GE8415@lkcl.net> References: <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> <42C2DC80.8070904@unify.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <42C2DC80.8070904@unify.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U10cgA018287 for ; Wed, 29 Jun 2005 21:00:38 -0400 (EDT) Received: from free.hands.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5U0x5dE015229 for ; Thu, 30 Jun 2005 00:59:05 GMT Date: Thu, 30 Jun 2005 02:08:38 +0100 From: Luke Kenneth Casson Leighton To: Casey Schaufler Cc: gyurdiev@redhat.com, SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630010838.GF8415@lkcl.net> References: <1120058832.17121.38.camel@celtics.boston.redhat.com> <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20050629165658.82487.qmail@web31609.mail.mud.yahoo.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jun 29, 2005 at 09:56:58AM -0700, Casey Schaufler wrote: > > > --- 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: > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U15dgA018392 for ; Wed, 29 Jun 2005 21:05:39 -0400 (EDT) Received: from web31614.mail.mud.yahoo.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with SMTP id j5U14g79012222 for ; Thu, 30 Jun 2005 01:04:42 GMT Message-ID: <20050630010443.9261.qmail@web31614.mail.mud.yahoo.com> Date: Wed, 29 Jun 2005 18:04:43 -0700 (PDT) From: Casey Schaufler Subject: Re: wish-list item for selinux policy analyss To: Luke Kenneth Casson Leighton , Ron Kuris Cc: SE-Linux In-Reply-To: <20050630010526.GE8415@lkcl.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --- Luke Kenneth Casson Leighton 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U1B5gA018441 for ; Wed, 29 Jun 2005 21:11:05 -0400 (EDT) Received: from web31609.mail.mud.yahoo.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with SMTP id j5U1A879012400 for ; Thu, 30 Jun 2005 01:10:08 GMT Message-ID: <20050630011009.79646.qmail@web31609.mail.mud.yahoo.com> Date: Wed, 29 Jun 2005 18:10:09 -0700 (PDT) From: Casey Schaufler Subject: Re: wish-list item for selinux policy analyss To: Luke Kenneth Casson Leighton Cc: gyurdiev@redhat.com, SE-Linux In-Reply-To: <20050630010838.GF8415@lkcl.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --- Luke Kenneth Casson Leighton wrote: > On Wed, Jun 29, 2005 at 09:56:58AM -0700, Casey > Schaufler wrote: > > > > > > --- 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: > > > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5U76ggA019876 for ; Thu, 30 Jun 2005 03:06:42 -0400 (EDT) Received: from mx1.redhat.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5U756Bs028127 for ; Thu, 30 Jun 2005 07:05:06 GMT Subject: Re: wish-list item for selinux policy analyss From: Ivan Gyurdiev Reply-To: gyurdiev@redhat.com To: Luke Kenneth Casson Leighton Cc: SE-Linux In-Reply-To: <20050630003700.GB8415@lkcl.net> References: <20050629021349.GA10219@lkcl.net> <1120058832.17121.38.camel@celtics.boston.redhat.com> <20050630003700.GB8415@lkcl.net> Content-Type: text/plain Date: Thu, 30 Jun 2005 03:05:56 -0400 Message-Id: <1120115156.26946.50.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5UBdrgA021002 for ; Thu, 30 Jun 2005 07:39:53 -0400 (EDT) Received: from free.hands.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5UBcqfl025122 for ; Thu, 30 Jun 2005 11:38:52 GMT Date: Thu, 30 Jun 2005 12:47:49 +0100 From: Luke Kenneth Casson Leighton To: Casey Schaufler Cc: gyurdiev@redhat.com, SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630114749.GH8415@lkcl.net> References: <20050630010838.GF8415@lkcl.net> <20050630011009.79646.qmail@web31609.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20050630011009.79646.qmail@web31609.mail.mud.yahoo.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5UBfAgA021028 for ; Thu, 30 Jun 2005 07:41:10 -0400 (EDT) Received: from free.hands.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5UBdWBs011421 for ; Thu, 30 Jun 2005 11:39:32 GMT Date: Thu, 30 Jun 2005 12:49:06 +0100 From: Luke Kenneth Casson Leighton To: Casey Schaufler Cc: Ron Kuris , SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630114906.GI8415@lkcl.net> References: <20050630010526.GE8415@lkcl.net> <20050630010443.9261.qmail@web31614.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20050630010443.9261.qmail@web31614.mail.mud.yahoo.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jun 29, 2005 at 06:04:43PM -0700, Casey Schaufler wrote: > > > --- Luke Kenneth Casson Leighton > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: wish-list item for selinux policy analyss From: Stephen Smalley To: gyurdiev@redhat.com Cc: Luke Kenneth Casson Leighton , SE-Linux In-Reply-To: <1120115156.26946.50.camel@localhost.localdomain> References: <20050629021349.GA10219@lkcl.net> <1120058832.17121.38.camel@celtics.boston.redhat.com> <20050630003700.GB8415@lkcl.net> <1120115156.26946.50.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 30 Jun 2005 08:16:31 -0400 Message-Id: <1120133791.11798.1.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5UCsjgA021751 for ; Thu, 30 Jun 2005 08:54:45 -0400 (EDT) Received: from sccrmhc13.comcast.net (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5UCr6Bs017449 for ; Thu, 30 Jun 2005 12:53:07 GMT Message-ID: <42C3EB52.4000208@tresys.com> Date: Thu, 30 Jun 2005 08:53:38 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Luke Kenneth Casson Leighton CC: SE-Linux Subject: Re: wish-list item for selinux policy analyss References: <20050629021349.GA10219@lkcl.net> In-Reply-To: <20050629021349.GA10219@lkcl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j5UKi3gA026426 for ; Thu, 30 Jun 2005 16:44:03 -0400 (EDT) Received: from free.hands.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id j5UKgwfl003568 for ; Thu, 30 Jun 2005 20:42:58 GMT Date: Thu, 30 Jun 2005 21:51:43 +0100 From: Luke Kenneth Casson Leighton To: Ivan Gyurdiev Cc: SE-Linux Subject: Re: wish-list item for selinux policy analyss Message-ID: <20050630205143.GC8421@lkcl.net> References: <20050629021349.GA10219@lkcl.net> <1120058832.17121.38.camel@celtics.boston.redhat.com> <20050630003700.GB8415@lkcl.net> <1120115156.26946.50.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1120115156.26946.50.camel@localhost.localdomain> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. -- -- http://lkcl.net -- -- 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.