[PATCH v28 22/25] Audit: Add record for multiple process LSM attributes

Casey Schaufler casey at schaufler-ca.com
Fri Aug 20 19:17:24 UTC 2021

On 8/20/2021 12:06 PM, Paul Moore wrote:
> On Thu, Aug 19, 2021 at 6:41 PM Casey Schaufler <casey at schaufler-ca.com> 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 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.

More information about the Linux-security-module-archive mailing list