policycoreutils: audit2allow -l doesn't work with dmesg pipe

policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Manoj Srivastava]

Hi,

        This has been reported against the Debian BTS.

        If you don't have auditd running and you run the following
 command you should expect no output:
load_policy ; dmesg|audit2allow -l

        But it doesn't happen, it seems that the -l option doesn't work
 when taking input from dmesg.

        manoj

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503252
-- 
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Daniel J Walsh]

On 08/23/2009 10:50 AM, Manoj Srivastava wrote:
> Hi,
> 
>         This has been reported against the Debian BTS.
> 
>         If you don't have auditd running and you run the following
>  command you should expect no output:
> load_policy ; dmesg|audit2allow -l
> 
>         But it doesn't happen, it seems that the -l option doesn't work
>  when taking input from dmesg.
> 
>         manoj
> 
> 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.

--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Russell Coker]

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.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Daniel J Walsh]

On 08/23/2009 04:11 PM, 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.

--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Russell Coker]

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.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Stephen Smalley]

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":


-- 
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Joshua Brindle]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]



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.

[-- Attachment #2: Type: text/html, Size: 3325 bytes --]

Re: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Manoj Srivastava]

On Tue, Sep 08 2009, 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":

        This patch has now been applied in Debian unstable.

        manoj
-- 
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
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: policycoreutils: audit2allow -l doesn't work with dmesg pipe

[Joshua Brindle]

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":
>
>

Merged in sepolgen 1.0.19

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