From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Abnormal End of Processes Date: Wed, 18 Apr 2007 13:27:51 -0400 Message-ID: <200704181327.51970.sgrubb@redhat.com> References: <200704181209.50302.sgrubb@redhat.com> <1176914844.19144.34.camel@code.and.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1176914844.19144.34.camel@code.and.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: James Antill Cc: Linux Audit List-Id: linux-audit@redhat.com On Wednesday 18 April 2007 12:47, James Antill wrote: > =C2=A0Does this deal with the case where the application catches SIGSEG= V, and > then calls abort() (or just raises SIGABRT). >>From this hook, no. It just doesn't have the visibility for that. > =C2=A0Also in a more general way, I'm pretty sure you'd also want to kn= ow > whenever abort()/raise(SIGABORT) is done, at least all the times I've > seen those calls it's the same thing as a SIGSEGV situation from the > applications POV. Not really, there are a surprising number of apps that consider abort() t= o be=20 a normal way of exiting when there's a minor problem. I've never seen any= app=20 catch SIGSEGV and then raise(sigabort). > =C2=A0The only thing I can think against this is that _very rarely_ a > sysadmin will do a "kill -ABRT" to stop a problem application ... which > I assume is why you've filtered it? No, its because you get a lot of programs ending with abort - hald-addon-= acpi=20 and dhcdbd to name a couple. > But even then is a "spurious" audit event that bad? It was frequent enough I didn't want that noise in the logs at this point= . If=20 those applications get cleaned up, I think we could allow abort() to go=20 through. -Steve