On Thu, Aug 19, 2021 at 6:41 PM Casey Schaufler [off-list ref] wrote:

On 8/18/2021 5:56 PM, Casey Schaufler wrote:

quoted

On 8/18/2021 5:47 PM, Paul Moore wrote:

quoted

...
I just spent a few minutes tracing the code paths up from audit
through netlink and then through the socket layer and I'm not seeing
anything obvious where the path differs from any other syscall;
current->audit_context *should* be valid just like any other syscall.
However, I do have to ask, are you only seeing these audit records
with a current->audit_context equal to NULL during early boot?

Nope. Sorry.

It looks as if all of the NULL audit_context cases are for either
auditd or systemd. Given what the events are, this isn't especially
surprising.

I think we may be back to the "early boot" theory.

Unless you explicitly enable audit on the kernel cmdline, e.g.
"audit=1", processes started before userspace enables audit will not
have a properly allocated audit_context; see the "if
(likely(!audit_ever_enabled))" check at the top of audit_alloc() for
the reason why.

I could be wrong here, but I suspect if you add "audit=1" to your
kernel command line those remaining cases of NULL audit_contexts will
resolve themselves.  If not, we still have work to do ... well, I mean
we still have (different) work to do even if this solves the mystery,
it's just that we can now explain what you are seeing :)

-- 
paul moore
www.paul-moore.com