From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: [PATCH] Handle timestamp 0.0 in auparse, was Re: audit-viewer help needed Date: Mon, 22 Sep 2008 19:38:37 -0500 Message-ID: <1222130317.6513.85.camel@homeserver> References: <1221782548.6783.30.camel@homeserver> <1221812917.2947.10.camel@amilo> <1221830658.6513.4.camel@homeserver> <1222126221.2685.81.camel@amilo> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1222126221.2685.81.camel@amilo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Miloslav =?UTF-8?Q?Trma=C4=8D?= Cc: linux-audit List-Id: linux-audit@redhat.com On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trma=C4=8D wrote: > Hello, > the attached patch modifies auparse not to handle timestamp 0.x > specially by using out-of-band information (parse_state =3D=3D EVENT_EM= PTY) > instead of assuming (au->le.e.sec =3D=3D 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. >=20 > The patch also decreases the assumed minimal length of a timestamp. >=20 > I have tested this only minimally - I have checked that (make check) > succeeds, and that audit-viewer doesn't crash on startup. >=20 > This patch fixes handling of the following Lenny's audit record: >=20 > > node=3Dhugo type=3DAVC msg=3Daudit(0.000:6760): avc: denied { recvf= rom } > > for pid=3D2589 comm=3D"lockd" saddr=3D127.0.0.1 src=3D687 daddr=3D12= 7.0.0.1 > > dest=3D111 netif=3Dlo scontext=3Dsystem_u:system_r:initrc_t:s0-s15:c0= .c1023 > > tcontext=3Dsystem_u:system_r:kernel_t:s15:c0.c1023 tclass=3Dassociati= on >=20 > 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? >=20 > 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=3Dlocal-hugo type=3DAVC msg=3Daudit(0.00= 0:6760): avc: denied { recvfrom } for pid=3D2589 comm=3D"lockd" saddr=3D= 127.0.0.1 src=3D687 daddr=3D127.0.0.1 dest=3D111 netif=3Dlo scontext=3Dsy= stem_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=3Dsystem_u:system_r:ker= nel_t:s15:c0.c1023 tclass=3Dassociation=20 /var/log/audit/audit.log.12:node=3Dlocal-hugo type=3DAVC msg=3Daudit(0.00= 0:381): avc: denied { read } for pid=3D2594 comm=3D"nfsd4" name=3D"v4r= ecovery" dev=3Ddm-0 ino=3D34482 scontext=3Dsystem_u:system_r:kernel_t:s15= :c0.c1023 tcontext=3Dsystem_u:object_r:var_lib_nfs_t:s0 tclass=3Ddir=20 /var/log/audit/audit.log.12:node=3Dlocal-hugo type=3DAVC msg=3Daudit(0.00= 0:5135): avc: denied { recvfrom } for pid=3D2595 comm=3D"lockd" saddr=3D= 127.0.0.1 src=3D701 daddr=3D127.0.0.1 dest=3D111 netif=3Dlo scontext=3Dsy= stem_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=3Dsystem_u:system_r:ker= nel_t:s15:c0.c1023 tclass=3Dassociation=20 /var/log/audit/audit.log.12:node=3Dlocal-hugo type=3DAVC msg=3Daudit(0.00= 0:388): avc: denied { read } for pid=3D2593 comm=3D"nfsd4" name=3D"v4r= ecovery" dev=3Ddm-0 ino=3D34482 scontext=3Dsystem_u:system_r:kernel_t:s15= :c0.c1023 tcontext=3Dsystem_u:object_r:var_lib_nfs_t:s0 tclass=3Ddir=20 /var/log/audit/audit.log.13:node=3Dlocal-hugo type=3DAVC msg=3Daudit(0.00= 0:380): avc: denied { read } for pid=3D2588 comm=3D"nfsd4" name=3D"v4r= ecovery" dev=3Ddm-0 ino=3D34482 scontext=3Dsystem_u:system_r:kernel_t:s15= :c0.c1023 tcontext=3Dsystem_u:object_r:var_lib_nfs_t:s0 tclass=3Ddir=20 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. --=20 LC (Lenny) Bruzenak lenny@magitekltd.com