Skip to contentSkip to conversation

audit: Match SELinux context in "user" records

PATCH In review Miloslav Trmač 2 participants 2 messages Nov 9, 2009 Audit

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 audit: Match SELinux context in "user" records

From: Miloslav Trmac <[email protected]>

Add support for matching by security label (e.g. SELinux context) of the sender of an user-space audit record.

The audit filter code already allows user space to configure such filters, but they were ignored during evaluation. This patch implements evaluation of these filters.

For example, after application of this patch, PAM authentication logs caused by cron can be disabled using
auditctl -a user,never -F subj_type=crond_t

---
 kernel/auditfilter.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)
kernel/auditfilter.c +12 -0
index a706040..50307c1 100644
@@ -1259,6 +1259,18 @@ static int audit_filter_user_rules(struct netlink_skb_parms *cb,
 		case AUDIT_LOGINUID:
 			result = audit_comparator(cb->loginuid, f->op, f->val);
 			break;
+		case AUDIT_SUBJ_USER:
+		case AUDIT_SUBJ_ROLE:
+		case AUDIT_SUBJ_TYPE:
+		case AUDIT_SUBJ_SEN:
+		case AUDIT_SUBJ_CLR:
+			if (f->lsm_rule)
+				result = security_audit_rule_match(cb->sid,
+								   f->type,
+								   f->op,
+								   f->lsm_rule,
+								   NULL);
+			break;
 		}
 
 		if (!result)
Signature · 1 line
1.6.2.5
maintainer Acked-by on v1 1/1
#1 lore raw
Quoted 9 lines · Miloslav Trmač

From: Miloslav Trmac <[email protected]>

Add support for matching by security label (e.g. SELinux context) of the sender of an user-space audit record.

The audit filter code already allows user space to configure such filters, but they were ignored during evaluation. This patch implements evaluation of these filters.

Quoted 5 lines

For example, after application of this patch, PAM authentication logs caused by cron can be disabled using
auditctl -a user,never -F subj_type=crond_t

I wish there was a way to stop sending these instead of dropping them later, but the functionality itself is not a horrid idea and this isn't a performance hot list (like the syscall list) so.....

(I actually talked to Al about it already and he'll queue it up for the next merge window)