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:
Signed-off-by: Joshua Brindle <method@manicmethod.com>
a3ccf607a2