Re: [Patch] SE Linux audit events
On Sat, 2005-12-03 at 08:32 -0500, Steve Grubb wrote:
On Tuesday 08 November 2005 10:32, Steve Grubb wrote:
> I think we need to add some SE Linux kernel message types for audit into
> the kernel and start patching the kernel to report these messages -
> including the information of previous value and new value.
Attached is a patch that hardwires important SE Linux events to the audit
system. Please Apply.
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
diff -urp linux-2.6.14.orig/security/selinux/selinuxfs.c
linux-2.6.14/security/selinux/selinuxfs.c
--- linux-2.6.14.orig/security/selinux/selinuxfs.c 2005-12-02 15:05:39.000000000 -0500
+++ linux-2.6.14/security/selinux/selinuxfs.c 2005-12-02 15:06:27.000000000 -0500
@@ -174,6 +179,9 @@ static ssize_t sel_write_disable(struct
if (new_value) {
length = selinux_disable();
+ audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
+ "selinux=0 auid=%u",
+ audit_get_loginuid(current->audit_context));
if (length < 0)
goto out;
}
Note that selinux_disable() could fail (if policy has previously been
loaded or SELinux was already disabled), so it seems like you want this
audit_log call moved after the check.
diff -urp linux-2.6.14.orig/security/selinux/ss/services.c
linux-2.6.14/security/selinux/ss/services.c
--- linux-2.6.14.orig/security/selinux/ss/services.c 2005-12-02 15:05:39.000000000 -0500
+++ linux-2.6.14/security/selinux/ss/services.c 2005-12-02 15:08:31.000000000 -0500
@@ -1760,6 +1760,15 @@ int security_set_bools(int len, int *val
printk(KERN_INFO "security: committed booleans { ");
for (i = 0; i < len; i++) {
+ if (!!values[i] != policydb.bool_val_to_struct[i]->state) {
+ audit_log(current->audit_context, GFP_ATOMIC,
+ AUDIT_MAC_CONFIG_CHANGE,
+ "bool=%s val=%d old_val=%d auid=%u",
+ policydb.p_bool_val_to_name[i],
+ !!values[i],
+ policydb.bool_val_to_struct[i]->state,
+ audit_get_loginuid(current->audit_context));
+ }
if (values[i]) {
policydb.bool_val_to_struct[i]->state = 1;
} else {
This interleaves the audit_log calls with the existing printk calls, which
could be unpleasant e.g. if no auditd is running. Offhand, I'd suggest
just dropping the printk statements from this function given your new audit_log
call. We may also want to look at moving this logging out of
POLICY_WRLOCK, only keeping the actual state update within the lock.
--
Stephen Smalley
National Security Agency