On Wed, May 14, 2025 at 5:16 PM Casey Schaufler [off-list ref] wrote:

On 5/14/2025 1:57 PM, Paul Moore wrote:

quoted

On Wed, May 14, 2025 at 3:30 PM Casey Schaufler [off-list ref] wrote:

quoted

On 5/13/2025 1:23 PM, Paul Moore wrote:

quoted

On Tue, May 13, 2025 at 12:39 PM Casey Schaufler [off-list ref] wrote:

quoted

On 4/9/2025 11:50 AM, Paul Moore wrote:

...

quoted

quoted

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.

-- 
paul-moore.com