On Wed, 2007-04-18 at 12:09 -0400, Steve Grubb wrote:
> Hi,
> 
> I have been working on some code that detects abnormal events based on 
> audit system events. One kind of event that we currently have no visibility for is
> when a program terminates due to segfault - which should never happen on a
> production machine. And if it did, you'd want to investigate it. Attached is a
> patch that collects these events and sends them into the audit system.
> 
> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> 
> 
> diff -urp linux-2.6.18.x86_64.orig/fs/exec.c linux-2.6.18.x86_64/fs/exec.c
> --- linux-2.6.18.x86_64.orig/fs/exec.c	2007-04-13 17:26:19.000000000 -0400
> +++ linux-2.6.18.x86_64/fs/exec.c	2007-04-13 17:25:34.000000000 -0400
> @@ -49,6 +49,7 @@
>  #include <linux/acct.h>
>  #include <linux/cn_proc.h>
>  #include <linux/audit.h>
> +#include <linux/selinux.h>
>  
>  #include <asm/uaccess.h>
>  #include <asm/mmu_context.h>
> @@ -1462,6 +1463,32 @@ int do_coredump(long signr, int exit_cod
>  	int fsuid = current->fsuid;
>  	int flag = 0;
>  	int ispipe = 0;
> +	extern int audit_enabled;
> +
> +	if (unlikely(audit_enabled) && signr != SIGQUIT && signr != SIGABRT) {

 Does this deal with the case where the application catches SIGSEGV, and
then calls abort() (or just raises SIGABRT).
 Also in a more general way, I'm pretty sure you'd also want to know
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.
 The 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? But even then is a "spurious" audit
event that bad?

-- 
James Antill <jantill@redhat.com>