Re: [RFC PATCH 2/2] [WIP] audit: allow other filter list types for AUDIT_DIR
2018-06-05 0:19 GMT+02:00 Paul Moore <paul(a)paul-moore.com>:
On Fri, Jun 1, 2018 at 4:05 PM, Richard Guy Briggs
<rgb(a)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.