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

[Paul Moore]

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.

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