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 <[EMAIL PROTECTED]>
>
>
> 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 <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
