Re: [PATCH] audit: add fields to exclude filter by reusing user filter
On Fri, Jun 3, 2016 at 4:24 PM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 16/06/03, Paul Moore wrote:
> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb(a)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 <rgb(a)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