Re: [PATCH] Handle timestamp 0.0 in auparse, was Re: audit-viewer help needed

[LC Bruzenak <lenny@magitekltd.com>]

On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
> Hello,
> the attached patch modifies auparse not to handle timestamp 0.x
> specially by using out-of-band information (parse_state == EVENT_EMPTY)
> instead of assuming (au->le.e.sec == 0) has a special meaning.  As far
> as I can see, this the two conditions are equivalent if no event has a
> timestamp 0.x.
> 
> The patch also decreases the assumed minimal length of a timestamp.
> 
> I have tested this only minimally - I have checked that (make check)
> succeeds, and that audit-viewer doesn't crash on startup.
> 
> This patch fixes handling of the following Lenny's audit record:
> 
> > node=hugo type=AVC msg=audit(0.000:6760): avc:  denied  { recvfrom }
> > for  pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1
> > dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
> > tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
> 
> I'm curious how this audit record could have been created (notabile is
> that the previous record has a sequence ID 6758 and a reasonable
> timestamp).  Lenny, Steve, any ideas?
> 
> Thank you,
> 	Mirek

I assume the timestamp is punched in the kernel audit code.
I decided to go rule out aggregation error and went looking on the
originating machine. I found a couple more:

[root@hugo ~]# grep "(0.000:" /var/log/audit/audit.log*
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:6760): avc:  denied  { recvfrom } for  pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1 dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association 
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:381): avc:  denied  { read } for  pid=2594 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482 scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir 
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:5135): avc:  denied  { recvfrom } for  pid=2595 comm="lockd" saddr=127.0.0.1 src=701 daddr=127.0.0.1 dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association 
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:388): avc:  denied  { read } for  pid=2593 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482 scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir 
/var/log/audit/audit.log.13:node=local-hugo type=AVC msg=audit(0.000:380): avc:  denied  { read } for  pid=2588 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482 scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir 

They all appear to be AVCs on denied read/recvfom, maybe there is a
timestamp bug in there?

Let me know if I can supply any data/diagnostics. I'll have to leave the
kernel code to experts for now...

Thx!
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com