On 8/20/2021 12:17 PM, Casey Schaufler wrote: > On 8/20/2021 12:06 PM, Paul Moore wrote: >> On Thu, Aug 19, 2021 at 6:41 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>> On 8/18/2021 5:56 PM, Casey Schaufler wrote: >>>> On 8/18/2021 5:47 PM, Paul Moore wrote: >>>>> ... >>>>> 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 found a hack-around that no one will like. I changed that check to be (likely(!audit_ever_enabled) && !lsm_multiple_contexts()) It probably introduces a memory leak and/or performance degradation, but it has the desired affect. >> >> 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 :) > Yup, adding "audit=1" to the command line appears to have gotten > systemd an audit context. It looks like user space enabling audit > doesn't assign an audit context to the existing systemd process. >
