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

[Casey Schaufler]

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 at 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/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 0d2c2a017ffc..5bc144c5f685 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -71,16 +71,22 @@ struct lsm_static_calls_table {
>  	#undef LSM_HOOK
>  } __packed __randomize_layout;
>  
> +#define LSM_ID_FLG_NONE			0x00000000
> +#define LSM_ID_FLG_PROP_SUBJ		0x00000001
> +#define LSM_ID_FLG_PROP_OBJ		0x00000002
> +
>  /**
>   * struct lsm_id - Identify a Linux Security Module.
>   * @lsm: name of the LSM, must be approved by the LSM maintainers
>   * @id: LSM ID number from uapi/linux/lsm.h
> + * @flags: LSM flags, see LSM_ID_FLG_XXX
>   *
>   * Contains the information that identifies the LSM.
>   */
>  struct lsm_id {
>  	const char *name;
>  	u64 id;
> +	u32 flags;
>  };
>  
>  /*
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 2fefaab6349f..db8592bed189 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1428,6 +1428,7 @@ struct lsm_blob_sizes apparmor_blob_sizes __ro_after_init = {
>  static const struct lsm_id apparmor_lsmid = {
>  	.name = "apparmor",
>  	.id = LSM_ID_APPARMOR,
> +	.flags = LSM_ID_FLG_PROP_SUBJ,
>  };
>  
>  static struct security_hook_list apparmor_hooks[] __ro_after_init = {
> 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.