[RFC PATCH 29/29] lsm: add support for counting lsm_prop support among LSMs

[Casey Schaufler]

On 5/14/2025 3:11 PM, Paul Moore wrote:
> On Wed, May 14, 2025 at 5:16 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 5/14/2025 1:57 PM, Paul Moore wrote:
>>> On Wed, May 14, 2025 at 3:30 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> On 5/13/2025 1:23 PM, Paul Moore wrote:
>>>>> On Tue, May 13, 2025 at 12:39 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>>>> On 4/9/2025 11:50 AM, Paul Moore wrote:
> ..
>
>>>> In my coming audit patch I changed where the counts of properties are
>>>> maintained from the LSM infrastructure to the audit subsystem, where they are
>>>> actually used. Instead of the LSM init code counting the property users, the
>>>> individual LSM init functions call an audit function that keeps track. BPF
>>>> could call that audit function if it loads a program that uses contexts. That
>>>> could happen after init, and the audit system would handle it properly.
>>>> Unloading the bpf program would be problematic. I honestly don't know whether
>>>> that's permitted.
>>> BPF programs can definitely go away, so that is something that would
>>> need to be accounted for in any solution.  My understanding is that
>>> once all references to a BPF program are gone, the BPF program is
>>> unloaded from the kernel.
>>>
>>> Perhaps the answer is that whenever the BPF LSM is enabled at boot,
>>> the audit subsystem always queries for subj/obj labels from the BPF
>>> LSM and instead of using the normal audit placeholder for missing
>>> values, "?", we simply don't log the BPF subj/obj fields.  I dislike
>>> the special case nature of the solution, but the reality is that the
>>> BPF is a bit "special" and we are going to need to have some special
>>> code to deal with it.
>> If BPF never calls audit_lsm_secctx() everything is fine, and the BPF
>> context(s) never result in an aux record. If BPF does call audit_lsm_secctx()
>> and there is another LSM that uses contexts you get the aux record, even
>> if the BPF program goes away. You will get an aux record with only one context.
>> This is not ideal, but provides the correct information. This all assumes that
>> BPF programs can call into the audit system, and that they deal with multiple
>> contexts within BPF. There could be a flag to audit_lsm_secctx() to delete the
>> entry, but that seems potentially dangerous.
> I think the answer to "can BPF programs call into the audit subsystem"
> is dependent on if they have the proper BPF kfuncs for the audit API.
> I don't recall seeing them post anything to the audit list about that,
> but it's also possible they did it without telling anyone (ala move
> fast, break things).  I don't think we would want to prevent BPF
> programs from calling into the normal audit API that other subsystems
> use, but we would need to look at that as it comes up.

I suggest that until the "BPF auditing doesn't work!!!" crisis hits
there's not a lot of point in going to heroic efforts to ensure all
the bases are covered. I'll move forward assuming that an LSM could
dynamically decide to call audit_lsm_secctx(), and that once it does
it will always show up in the aux record, even if that means subj_bpf=?
shows up every time.