On 5/15/2025 11:13 AM, Paul Moore wrote: > On Thu, May 15, 2025 at 10:12 AM Casey Schaufler <[email protected]> > wrote: >> On 5/14/2025 3:11 PM, Paul Moore wrote: >>> On Wed, May 14, 2025 at 5:16 PM Casey Schaufler <[email protected]> >>> wrote: >>>> On 5/14/2025 1:57 PM, Paul Moore wrote: >>>>> On Wed, May 14, 2025 at 3:30 PM Casey Schaufler <[email protected]> >>>>> wrote: >>>>>> On 5/13/2025 1:23 PM, Paul Moore wrote: >>>>>>> On Tue, May 13, 2025 at 12:39 PM Casey Schaufler >>>>>>> <[email protected]> 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. > My only concern is that I suspect most/all of the major distro enable > the BPF LSM by default which means that suddenly a lot of users/admins > are going to start seeing the multi-subj/obj labeling scheme only to > have an empty field logged.
That will only occur if a BPF program says it want to provide contexts and then stops doing so, either by exiting or in error. As no BPF programs currently use audit, it seems that this is at worst a future problem. Should BPF programs develop the ability to use audit the behavior will need to be documented. I don't see how we can anticipate what they'll end up trying.
