Re: [PATCH] Handle timestamp 0.0 in auparse, was Re: audit-viewer help needed
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(a)magitekltd.com