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

[Paul Moore <paul@paul-moore.com>]

On Wed, May 14, 2025 at 3:30 PM Casey Schaufler <casey@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@schaufler-ca.com> wrote:
> >> On 4/9/2025 11:50 AM, Paul Moore wrote:
> >>> Add two new variables, lsm_count_prop_subj and lsm_count_prop_obj, to
> >>> count the number of lsm_prop entries for subjects and objects across all
> >>> of the enabled LSMs.  Future patches will use this to continue the
> >>> conversion towards the lsm_prop struct.
> >>>
> >>> Signed-off-by: Paul Moore <paul@paul-moore.com>
> >>> ---
> >>>  include/linux/lsm_hooks.h         | 6 ++++++
> >>>  security/apparmor/lsm.c           | 1 +
> >>>  security/bpf/hooks.c              | 1 +
> >>>  security/commoncap.c              | 1 +
> >>>  security/integrity/evm/evm_main.c | 1 +
> >>>  security/integrity/ima/ima_main.c | 1 +
> >>>  security/ipe/ipe.c                | 1 +
> >>>  security/landlock/setup.c         | 1 +
> >>>  security/loadpin/loadpin.c        | 1 +
> >>>  security/lockdown/lockdown.c      | 1 +
> >>>  security/lsm.h                    | 4 ++++
> >>>  security/lsm_init.c               | 6 ++++++
> >>>  security/safesetid/lsm.c          | 1 +
> >>>  security/security.c               | 3 +++
> >>>  security/selinux/hooks.c          | 1 +
> >>>  security/smack/smack_lsm.c        | 1 +
> >>>  security/tomoyo/tomoyo.c          | 1 +
> >>>  security/yama/yama_lsm.c          | 1 +
> >>>  18 files changed, 33 insertions(+)
> > ..
> >
> >>> diff --git a/security/bpf/hooks.c b/security/bpf/hooks.c
> >>> index 40efde233f3a..c72df6ff69f7 100644
> >>> --- a/security/bpf/hooks.c
> >>> +++ b/security/bpf/hooks.c
> >>> @@ -18,6 +18,7 @@ static struct security_hook_list bpf_lsm_hooks[] __ro_after_init = {
> >>>  static const struct lsm_id bpf_lsmid = {
> >>>       .name = "bpf",
> >>>       .id = LSM_ID_BPF,
> >>> +     .flags = LSM_ID_FLG_PROP_SUBJ | LSM_ID_FLG_PROP_OBJ,
> >> There's a problem here. BPF can have properties, but usually does not.
> >> Unless there's a bpf program loaded that provides them it is incorrect
> >> to use these flags. You can't know that at initialization.
> >>
> >> I have an alternative that will address this that I will propose
> >> shortly.
> > Okay, thanks.
>
> 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.

Of course I'm open to other ideas too ...

-- 
paul-moore.com