2018-06-05 0:19 GMT+02:00 Paul Moore <p...@paul-moore.com>: > On Fri, Jun 1, 2018 at 4:05 PM, Richard Guy Briggs <r...@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. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit