On Thu, May 15, 2025 at 3:41 PM Casey Schaufler <[email protected]> wrote: > 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.
Okay, I must have misunderstood your proposal; I'll take a look once it is posted, that should help clear things up. -- paul-moore.com
