[RFC PATCH 2/2] [WIP] audit: allow other filter list types for AUDIT_DIR

[Ondrej Mosnacek]

2018-06-05 0:19 GMT+02:00 Paul Moore <paul at paul-moore.com>:
> On Fri, Jun 1, 2018 at 4:05 PM, Richard Guy Briggs <rgb at redhat.com> wrote:
>> On 2018-06-01 10:12, Ondrej Mosnacek wrote:
>
> ...
>
>>> audit_receive_msg  --  this function doesn't work with context at all,
>>> so I wasn't sure if audit_filter should consider it being NULL or if
>>> it should get it from the current task. My hunch is the second option
>>> is the right one, but the first one is safer (AUDIT_DIR will simply
>>> never be checked here). I don't have such insight into the logic of
>>> audit_context's lifetime, so I need someone to tell me what makes more
>>> sense here.
>
> Given the nature of audit_receive_msg(), would it ever match on an
> AUDIT_DIR field?  I don't think it would since there aren't really any
> vfs accesses that occur in the source of sending a netlink message
> down to the kernel ... am I missing something?

Probably not, but we still need to decide whether to pass the current
task's context or not. Both options (NULL and audit_context()) seem to
be benign for now, but I need you to pick one of those that you prefer
so I can send a final patch.

>
>> That is starting to work with context.  The recent FEATURE_CHANGE patch
>> to connect records of the same event uses current->audit_context (now
>> audit_context()) from audit_log_feature_change() called from
>> audit_set_feature() called from audit_receive_msg().
>>
>> There is also a work in progress to convert all the CONFIG_CHANGE
>> records over.  I'm just trying to track down all the instances.
>
> This will be a nice improvement.
>
> --
> paul moore
> www.paul-moore.com

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.