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

LC Bruzenak
2008-09-23T00:38:37Z

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