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

Casey Schaufler casey at schaufler-ca.com
Fri Aug 20 23:48:35 UTC 2021

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 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 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.

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