Re: [PATCH] audit: add fields to exclude filter by reusing user filter

[Richard Guy Briggs]

On 16/06/03, Paul Moore wrote:
> On Fri, Jun 3, 2016 at 4:24 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> > On 16/06/03, Paul Moore wrote:
> >> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> 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 <rgb@xxxxxxxxxx>
> >> > ---
> >> >  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.

Yes, I was thinking that audit_filter_type/user() could be a sub-call of
audit_filter_rules(), but not sure the clearest way to implement that.

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

I had a first crack at it last week and it wasn't just a simple
inversion, but had rule action and error differences too, so I had some
doubts about how worthwhile the refactor would be in terms of reducing
duplicaiton and making things clearer, but had another go today and am
satisfied with the resulting patch posted today.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@xxxxxxxxxx>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635