From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4AB0FE47.3020007@manicmethod.com> Date: Wed, 16 Sep 2009 11:03:35 -0400 From: Joshua Brindle MIME-Version: 1.0 To: russell@coker.com.au CC: Stephen Smalley , Daniel J Walsh , selinux@tycho.nsa.gov, 503252-forwarded@bugs.debian.org, Eric Paris Subject: Re: policycoreutils: audit2allow -l doesn't work with dmesg pipe References: <87d46mvb33.fsf@anzu.internal.golden-gryphon.com> <200908240611.58935.russell@coker.com.au> <4A928943.3040609@redhat.com> <200908242337.51448.russell@coker.com.au> <1252419007.13634.346.camel@moss-pluto.epoch.ncsc.mil> In-Reply-To: <1252419007.13634.346.camel@moss-pluto.epoch.ncsc.mil> Content-Type: multipart/alternative; boundary="------------010305090303060709090200" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------010305090303060709090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Smalley wrote: > On Mon, 2009-08-24 at 23:37 +1000, Russell Coker wrote: > >> On Mon, 24 Aug 2009, Daniel J Walsh wrote: >> >>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503252 >>>>>> >>>>> audit2allow -l is looking for the load_policy message which does not go >>>>> to the dmesg, /var/log/messages. Therefore the tool has no idea when >>>>> policy was last loaded. >>>>> >>>> That would be a kernel bug then. >>>> >>> Well I believe the messages that are intercepted by the audit.log do not go >>> into dmesg, by design. Although Steve, James or Eric could probably say for >>> sure. >>> >> When auditd is not running on a Debian system with CentOS kernel >> 2.6.18-92.1.13.el5xen or Debian/Lenny kernel 2.6.26-2-xen-686 then nothing >> goes to the kernel message log which is interpreted by audit2allow as a >> candidate for the "-l" functionality. >> >> It's OK if all the AVC messages go to the audit log and "dmesg|audit2allow -l" >> gives no output. But if all AVC messages other than the load_policy message >> go to the kernel message log then it's a bug. >> > > Originally audit2allow used the avc: allowed message generated by > auditallow statement for load_policy to identify policy reloads. Later > it was switched to use the MAC_POLICY_LOAD events generated by the audit > framework. Those events should still get logged via printk if auditd is > not running, but it appears that the code (audit_printk_skb) will then > log the type= field as an integer rather than a string, and > audit2allow/sepolgen only looks for the string MAC_POLICY_LOAD. > > So I suspect that this would be resolved by modifying sepolgen/audit.py > to also match on type=1403 for load messages. Try this: > > diff --git a/sepolgen/src/sepolgen/audit.py b/sepolgen/src/sepolgen/audit.py > index 4717dae..efcc40d 100644 > --- a/sepolgen/src/sepolgen/audit.py > +++ b/sepolgen/src/sepolgen/audit.py > @@ -314,7 +314,7 @@ class AuditParser: > elif i == "security_compute_sid:": > msg = ComputeSidMessage(line) > found = True > - elif i == "type=MAC_POLICY_LOAD": > + elif i == "type=MAC_POLICY_LOAD" or i == "type=1403": > msg = PolicyLoadMessage(line) > found = True > elif i == "type=AVC_PATH": > > Russel, does this resolve your issue? I don't have a system setup like yours to test on. --------------010305090303060709090200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stephen Smalley wrote:

On Mon, 2009-08-24 at 23:37 +1000, Russell Coker wrote:

On Mon, 24 Aug 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503252

audit2allow -l is looking for the load_policy message which does not go
to the dmesg, /var/log/messages.  Therefore the tool has no idea when
policy was last loaded.

That would be a kernel bug then.

Well I believe the messages that are intercepted by the audit.log do not go
into dmesg, by design. Although Steve, James or Eric could probably say for
sure.

When auditd is not running on a Debian system with CentOS kernel 
2.6.18-92.1.13.el5xen or Debian/Lenny kernel 2.6.26-2-xen-686 then nothing 
goes to the kernel message log which is interpreted by audit2allow as a 
candidate for the "-l" functionality.

It's OK if all the AVC messages go to the audit log and "dmesg|audit2allow -l" 
gives no output.  But if all AVC messages other than the load_policy message 
go to the kernel message log then it's a bug.


Originally audit2allow used the avc: allowed message generated by
auditallow statement for load_policy to identify policy reloads.  Later
it was switched to use the MAC_POLICY_LOAD events generated by the audit
framework.  Those events should still get logged via printk if auditd is
not running, but it appears that the code (audit_printk_skb) will then
log the type= field as an integer rather than a string, and
audit2allow/sepolgen only looks for the string MAC_POLICY_LOAD.

So I suspect that this would be resolved by modifying sepolgen/audit.py
to also match on type=1403 for load messages.  Try this:

diff --git a/sepolgen/src/sepolgen/audit.py b/sepolgen/src/sepolgen/audit.py
index 4717dae..efcc40d 100644
--- a/sepolgen/src/sepolgen/audit.py
+++ b/sepolgen/src/sepolgen/audit.py
@@ -314,7 +314,7 @@ class AuditParser:
             elif i == "security_compute_sid:":
                 msg = ComputeSidMessage(line)
                 found = True
-            elif i == "type=MAC_POLICY_LOAD":
+            elif i == "type=MAC_POLICY_LOAD" or i == "type=1403":
                 msg = PolicyLoadMessage(line)
                 found = True
             elif i == "type=AVC_PATH":

Russel, does this resolve your issue? I don't have a system setup like yours to test on.
--------------010305090303060709090200-- -- 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.