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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGH-KgtcN0U=ak1rAx-puRa9f7xwaFxwh9VJGE4fwa0RD0jKRQ@mail.gmail.com>
Date:	Fri, 3 Jun 2016 16:31:46 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	Richard Guy Briggs <rgb@...hat.com>
Cc:	Paul Moore <paul@...l-moore.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org
Subject: 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@...hat.com> wrote:
> On 16/06/03, Paul Moore wrote:
>> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb@...hat.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@...hat.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