From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Grubb <sgrubb@redhat.com>
Subject: Re: [PATCH] Handle timestamp 0.0 in auparse,
	was Re: audit-viewer help needed
Date: Sat, 18 Oct 2008 11:51:17 -0400
Message-ID: <200810181151.17999.sgrubb@redhat.com>
References: <1221782548.6783.30.camel@homeserver>
	<1222130317.6513.85.camel@homeserver>
	<1222131479.2685.92.camel@amilo>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Return-path: <linux-audit-bounces@redhat.com>
In-Reply-To: <1222131479.2685.92.camel@amilo>
Content-Disposition: inline
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: linux-audit@redhat.com
List-Id: linux-audit@redhat.com

On Monday 22 September 2008 20:57:59 Miloslav Trma=C4=8D wrote:
> LC Bruzenak p=C3=AD=C5=A1e v Po 22. 09. 2008 v 19:38 -0500:
> > On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trma=C4=8D wrote:
> > > > node=3Dhugo type=3DAVC msg=3Daudit(0.000:6760): <SNIP> comm=3D"lo=
ckd"
> > >
> > > 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?
> >
> > I found a couple more:
> >
> > [root@hugo ~]# grep "(0.000:" /var/log/audit/audit.log*
> > <SNIP> type=3DAVC msg=3Daudit(0.000:6760): <SNIP> comm=3D"lockd"
> > <SNIP> type=3DAVC msg=3Daudit(0.000:381): <SNIP> comm=3D"nfsd4"
>
> I think I can see what's going on.  Those are kernel threads; when they
> are created, an audit context is created and zeroed.  The timestamp is
> set on system call entry in ordinary threads, but there is no system
> call entry in kernel threads, so the original zero timestamp is used in
> all audit records related to kernel threads.
>
> I'm not sure how to fix it, though.  Perhaps identify "operation start"
> points in kernel threads, and update the timestamps in their audit
> contexts at that time?

Eric, Al,

Any ideas how to fix this?

Thanks,
-Steve