From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Wulf Subject: Re: ausearch checkpoint capability Date: Mon, 18 Aug 2014 15:29:32 -0700 Message-ID: <1408400972.77094.YahooMailNeo@web141603.mail.bf1.yahoo.com> References: <1408145116.1503.53.camel@swtf.swtf.dyndns.org> <26086601.oGHCGWl4C5@x2> <1408398590.845.3.camel@swtf.swtf.dyndns.org> <1754950.itjc35GDGM@x2> Reply-To: Joe Wulf Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8273310022617314013==" Return-path: Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7IMTbxt020256 for ; Mon, 18 Aug 2014 18:29:37 -0400 Received: from nm32-vm7.bullet.mail.bf1.yahoo.com (nm32-vm7.bullet.mail.bf1.yahoo.com [72.30.239.143]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7IMTYaf022319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 18 Aug 2014 18:29:35 -0400 In-Reply-To: <1754950.itjc35GDGM@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb , "burn@swtf.dyndns.org" Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com --===============8273310022617314013== Content-Type: multipart/alternative; boundary="-221842591-1428010417-1408400972=:77094" ---221842591-1428010417-1408400972=:77094 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This makes sense to me.=A0 I am all for it.=0A=0A=A0 +1=0A=0AR,=0A-Joe=0A= =0A=0A=0A>________________________________=0A> From: Steve Grubb =0A>To: burn@swtf.dyndns.org =0A>Cc: linux-audit@redhat.com =0A>Se= nt: Monday, August 18, 2014 5:59 PM=0A>Subject: Re: ausearch checkpoint cap= ability=0A> =0A>=0A>Hello,=0A>=0A>On Tuesday, August 19, 2014 07:49:50 AM B= urn Alting wrote:=0A>> Just to confirm:=0A>> =0A>> the patch would modify t= he --start command line processing to accept=0A>> a string argument of 'che= ckpoint-time' AND if a checkpoint file has also=0A>> been provided via the = --checkpoint arg AND there is a timestamp within=0A>> the specified file, w= e use the timestamp stored within the file?=0A>=0A>Yes. I am close to doing= a new release of the audit package. I am kind of =0A>aiming towards the en= d of this week. If its ready by then, I'll include it in =0A>the new releas= e. If not, maybe next release.=0A>=0A>Also, if anyone else has bugs to repo= rt, patches to send, etc. now would be a =0A>good time if they needed it to= go out soonish.=0A>=0A>Thanks,=0A>=0A>=0A>=0A>=0A>-Steve=0A>=0A>=0A>> On M= on, 2014-08-18 at 14:13 -0400, Steve Grubb wrote:=0A>> > Hello,=0A>> > =0A>= > > On Saturday, August 16, 2014 09:25:16 AM Burn Alting wrote:=0A>> > > On= e of the issues with ausearch's checkpoint code is how to recover from=0A>>= > > failures. A classic failure is to perform a checkpoint on a busy syste= m=0A>> > > and then delay too long before running the next invocation of au= search=0A>> > > and as a result of the delay, the checkpointed event cannot= be found in=0A>> > > the files in /var/log/audit. There are other failures= , such as re-use of=0A>> > > inodes etc.=0A>> > > =0A>> > > For those of yo= u who haven't noted the ausearch --checkpoint change, it=0A>> > > basically= records the details of the last complete audit event it=0A>> > > processed= or printed in a checkpoint file. It records not only the event=0A>> > > ti= me, but also the event node, serial, type and the file device and=0A>> > > = inode. Thus, when you next invoke ausearch with this option, the next=0A>> = > > event to process is the next complete event since the one recorded.=0A>= > > > =0A>> > > Should an error occur when attempting to find the next comp= lete event to=0A>> > > process, ausearch will exit. At this point, I believ= e the best recovery=0A>> > > action is to extract only the event time from = the checkpoint file and=0A>> > > ask for all complete events after that tim= e (i.e. as opposed to the=0A>> > > usual action of comparing time, event id= , type, log file details etc).=0A>> > =0A>> > Would anyone be opposed to ma= king that the default behavior?=0A>> > =0A>> > > There are at last two solu= tions:=0A>> > > a. We can patch ausearch to take a --checkpoint-time-only f= lag which=0A>> > > means ausearch will look for all events since the time i= n the checkpoint=0A>> > > file. This provides the best granularity in time = as it goes down to=0A>> > > msecs.=0A>> > =0A>> > I am worried about the pr= oliferation of command line switches. I'd rather=0A>> > make a new --start = target. e.g. --start checkpoint-time.=0A>> > =0A>> > > b. We extract the ti= mestamp from the checkpoint file, convert it to a=0A>> > > date and time an= d use ausearch's --start option to find all events since=0A>> > > the time = in the checkpoint file.=0A>> > > =0A>> > > The first provides greater granu= larity in time as it goes to msecs.=0A>> > =0A>> > If one is the timestamp = of the file, that might be misleading. I don't=0A>> > know if touching a fi= le is an auditable event. No time to investigate=0A>> > right now either. I= 'd rather see the time taken from within the file.=0A>> > =0A>> > > I can p= rovide a patch. Do you want it?=0A>> > =0A>> > Sure, if its based on a --st= art target.=0A>> > =0A>> > -Steve=0A>=0A>--=0A>Linux-audit mailing list=0A>= Linux-audit@redhat.com=0A>https://www.redhat.com/mailman/listinfo/linux-aud= it=0A>=0A>=0A> ---221842591-1428010417-1408400972=:77094 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This makes sense to= me.  I am all for it.

&n= bsp; +1

R,
-Joe

From: Steve Grubb <sgrubb@redhat.com&= gt;
To: burn@swtf.dynd= ns.org
Cc: linux-audit= @redhat.com
Sent: Mon= day, August 18, 2014 5:59 PM
Subj= ect: Re: ausearch checkpoint capability

Hello,

= On Tuesday, August 19, 2014 07:49:50 AM Burn Alting wrote:
> Just to confirm:
>
> the = patch would modify the --start command line processing to accept
> a string argument of 'checkpoint-time' AND if a checkpoint f= ile has also
> been provided via the --checkpoint arg = AND there is a timestamp within
> the specified file, = we use the timestamp stored within the file?

Yes. I am close to doing a new release of the audit package. I am ki= nd of
aiming towards the end of this week. If its ready = by then, I'll include it in
the new release. If not, may= be next release.

Also, if anyone else = has bugs to report, patches to send, etc. now would be a
good time if they needed it to go out soonish.

Thanks,



-Steve


> On Mon, 2014-08-18 at 14:13 -0400, Steve Grubb wrote:> > Hello,
> >
> > On Saturday, August 16, 2014 09:25:16 AM Burn Alting wrote:<= br clear=3D"none">> > > One of the issues with ausearch's checkpoi= nt code is how to recover from
> > > failures. A= classic failure is to perform a checkpoint on a busy system
> > > and then delay too long before running the next invocati= on of ausearch
> > > and as a result of the dela= y, the checkpointed event cannot be found in
> > &g= t; the files in /var/log/audit. There are other failures, such as re-use of=
> > > inodes etc.
> > >
> = > > For those of you who haven't noted the ausearch --checkpoint chan= ge, it
> > > basically records the details of th= e last complete audit event it
> > > processed o= r printed in a checkpoint file. It records not only the event
> > > time, but also the event node, serial, type and the fil= e device and
> > > inode. Thus, when you next in= voke ausearch with this option, the next
> > > e= vent to process is the next complete event since the one recorded.
> > >
> > > Should an error = occur when attempting to find the next complete event to
= > > > process, ausearch will exit. At this point, I believe the be= st recovery
> > > action is to extract only the = event time from the checkpoint file and
> > > ask for all compl= ete events after that time (i.e. as opposed to the
> &= gt; > usual action of comparing time, event id, type, log file details e= tc).
> >
> > Would anyone = be opposed to making that the default behavior?
> >=
> > > There are at last two solutions:
> > > a. We can patch ausearch to take a --checkpoint-t= ime-only flag which
> > > means ausearch will lo= ok for all events since the time in the checkpoint
> &= gt; > file. This provides the best granularity in time as it goes down t= o
> > > msecs.
> >
> > I am worried about the proliferation of command lin= e switches. I'd rather
> > make a new --start targe= t. e.g. --start checkpoint-time.
> >
> > = > b. We extract the timestamp from the checkpoint file, convert it to a<= br clear=3D"none">> > > date and time and use ausearch's --start o= ption to find all events since
> > > the time in= the checkpoint file.
> > >
&= gt; > > The first provides greater granularity in time as it goes to = msecs.
> >
> > If one is t= he timestamp of the file, that might be misleading. I don't
> > know if touching a file is an auditable event. No time to inve= stigate
> > right now either. I'd rather see the ti= me taken from within the file.
> >
> > > I can provide a patch. Do you want it?
= > >
> > Sure, if its based on a --start targ= et.
> >
> > -Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-= audit


---221842591-1428010417-1408400972=:77094-- --===============8273310022617314013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============8273310022617314013==--