On Fri, Jun 3, 2016 at 4:24 PM, Richard Guy Briggs <r...@redhat.com> wrote: > On 16/06/03, Paul Moore wrote: >> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <r...@redhat.com> wrote: >> > RFE: add additional fields for use in audit filter exclude rules >> > https://github.com/linux-audit/audit-kernel/issues/5 >> > >> > Re-factor audit_filter_type() to use audit_filter_user_rules() to enable >> > exclude filter to additionally filter on PID, UID, GID, AUID, >> > LOGINUID_SET, SUBJ_*. >> > >> > Add check in audit_filter_user() to quit early if list is empty. >> > >> > Signed-off-by: Richard Guy Briggs <r...@redhat.com> >> > --- >> > kernel/auditfilter.c | 22 +++++++++------------- >> > 1 files changed, 9 insertions(+), 13 deletions(-) >> >> I like the consolidation between audit_filter_type() and >> audit_filter_user(), I like it so much I think we should take it >> further. Let's consolidate both functions into a single function (say >> audit_filter()?) and update the callers to use the new function. This >> shouldn't be hard as the only callers are audit_receive_msg() and >> audit_log_start(); you'll need to be careful as the return values of >> the current functions are opposite of each other, but it should be >> easy enough to update one of the callers. >> >> Sound reasonable? > > Potentially... I was even eyeing kernel/auditsc.c::audit_filter_rules() > for re-factoring...
It's possible that we may be able to do some work on eliminating duplication between the audit_filter_user()/audit_filter_type() and audit_filter_rules(), but we'll always need audit_filter_rules() simply because it can filter on more things, e.g. it has access to object information. I would suggest working on just audit_filter_user() and audit_filter_type() right now so we can get something ready for upstream before -rc5 or so, and then look into possible refactoring with audit_filter_rules(). -- paul moore security @ redhat
