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(a)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(a)redhat.com>