11:09 a.m.
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) {
+ struct audit_buffer *ab;
+ u32 sid;
+
+ ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
+ audit_log_format(ab, "auid=%u uid=%u gid=%u",
+ audit_get_loginuid(current->audit_context),
+ current->uid, current->gid);
+ selinux_get_task_sid(current, &sid);
+ if (sid) {
+ char *ctx = NULL;
+ u32 len;
+
+ if (selinux_ctxid_to_string(sid, &ctx, &len))
+ audit_log_format(ab, " ssid=%u", sid);
+ else
+ audit_log_format(ab, " subj=%s", ctx);
+ kfree(ctx);
+ }
+ audit_log_format(ab, " pid=%d comm=", current->pid);
+ audit_log_untrustedstring(ab, current->comm);
+ audit_log_format(ab, " sig=%ld", signr);
+ audit_log_end(ab);
+ }
binfmt = current->binfmt;
if (!binfmt || !binfmt->core_dump)
diff -urp linux-2.6.18.x86_64.orig/include/linux/audit.h
linux-2.6.18.x86_64/include/linux/audit.h
--- linux-2.6.18.x86_64.orig/include/linux/audit.h 2007-04-13 17:26:21.000000000 -0400
+++ linux-2.6.18.x86_64/include/linux/audit.h 2007-04-13 17:20:37.000000000 -0400
@@ -111,6 +111,7 @@
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG 1799
#define AUDIT_ANOM_PROMISCUOUS 1700 /* Device changed promiscuous mode */
+#define AUDIT_ANOM_ABEND 1701 /* Process ended abnormally */
#define AUDIT_KERNEL 2000 /* Asynchronous audit record. NOT A REQUEST. */
11:47 a.m.
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>
12:27 p.m.
On Wednesday 18 April 2007 12:47, James Antill wrote:
Does this deal with the case where the application catches SIGSEGV,
and
then calls abort() (or just raises SIGABRT).
From this hook, no. It just doesn't have the visibility for that.
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.
Not really, there are a surprising number of apps that consider abort() to be
a normal way of exiting when there's a minor problem. I've never seen any app
catch SIGSEGV and then raise(sigabort).
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?
No, its because you get a lot of programs ending with abort - hald-addon-acpi
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
those applications get cleaned up, I think we could allow abort() to go
through.
-Steve
3:06 p.m.
On Wed, Apr 18, 2007 at 12:09:50PM -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>
I'd suggest taking that into a separate function somewhere in kernel/audit*.c;
no need to clutter fs/exec.c with it. Leave if (unlikely(audit_enabled)) in
inlined wrapper as usual, pass signr as argument...
6457
days inactive
6457
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Alexander Viro -
James Antill -
Steve Grubb