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

From: Paul Moore
Date: Fri Jun 03 2016 - 16:31:56 EST

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
>> >
>> >
>> > Re-factor audit_filter_type() to use audit_filter_user_rules() to enable
>> > exclude filter to additionally filter on PID, UID, GID, AUID,
>> >
>> > 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.

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