Re: [PATCH v2] lsm,selinux: Add LSM blob support for BPF objects

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

On Jul 22, 2025 Blaise Boscaccy <bboscaccy@linux.microsoft.com> wrote:
> 
> This patch introduces LSM blob support for BPF maps, programs, and
> tokens to enable LSM stacking and multiplexing of LSM modules that
> govern BPF objects. Additionally, the existing BPF hooks used by
> SELinux have been updated to utilize the new blob infrastructure,
> removing the assumption of exclusive ownership of the security
> pointer.
> 
> Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
> ---
> v2:
> - Use lsm_blob_alloc
> - Remove unneded null check
> - ifdef guard bpf alloc helpers
> ---
>  include/linux/lsm_hooks.h         |  3 ++
>  security/security.c               | 86 +++++++++++++++++++++++++++++--
>  security/selinux/hooks.c          | 56 ++++----------------
>  security/selinux/include/objsec.h | 17 ++++++
>  4 files changed, 113 insertions(+), 49 deletions(-)

This looks good to me, one nit/question below ...

> @@ -5684,7 +5731,16 @@ int security_bpf_prog(struct bpf_prog *prog)
>  int security_bpf_map_create(struct bpf_map *map, union bpf_attr *attr,
>  			    struct bpf_token *token, bool kernel)
>  {
> -	return call_int_hook(bpf_map_create, map, attr, token, kernel);
> +	int rc = 0;

I understand the motivation behind initializing @rc to zero, but to be
honest it is redundant and will surely result in a follow on patch from
someone to remove the initialization.

Do you have any objection to me removing the initialization during the
merge?  This would obviously apply to the other two as well.

> +	rc = lsm_bpf_map_alloc(map);
> +	if (unlikely(rc))
> +		return rc;
> +
> +	rc = call_int_hook(bpf_map_create, map, attr, token, kernel);
> +	if (unlikely(rc))
> +		security_bpf_map_free(map);
> +	return rc;
>  }

--
paul-moore.com