2009-11-09 15:10:47

by Miloslav Trmac

Subject: [PATCH] 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

Signed-off-by: Miloslav Trmac <[email protected]>
---
kernel/auditfilter.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index a706040..50307c1 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -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)
--
1.6.2.5

2009-11-09 18:21:11

by Eric Paris

Subject: Re: [PATCH] audit: Match SELinux context in "user" records

On Mon, 2009-11-09 at 16:10 +0100, Miloslav Trmač wrote:
> 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
>
> Signed-off-by: Miloslav Trmac <[email protected]>

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.....

Acked-by: Eric Paris <[email protected]>

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