linux-kernel - Re: [PATCH] lsm,selinux: Add LSM blob support for BPF objects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <941986e9f4f295f247e5982002e16fe9@paul-moore.com>
Date: Wed, 16 Jul 2025 22:11:59 -0400
From: Paul Moore <paul@...l-moore.com>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Stephen Smalley <stephen.smalley.work@...il.com>, Ondrej Mosnacek <omosnace@...hat.com>, Casey Schaufler <casey@...aufler-ca.com>, John Johansen <john.johansen@...onical.com>, Blaise Boscaccy <bboscaccy@...ux.microsoft.com>, Christian Göttsche <cgzones@...glemail.com>, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, selinux@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH] lsm,selinux: Add LSM blob support for BPF objects

On Jul 15, 2025 Blaise Boscaccy <bboscaccy@...ux.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@...ux.microsoft.com>
> ---
>  include/linux/lsm_hooks.h         |   3 +
>  security/security.c               | 120 +++++++++++++++++++++++++++++-
>  security/selinux/hooks.c          |  56 +++-----------
>  security/selinux/include/objsec.h |  17 +++++
>  4 files changed, 147 insertions(+), 49 deletions(-)

...

> @@ -835,6 +841,72 @@ static int lsm_bdev_alloc(struct block_device *bdev)
>  	return 0;
>  }
>  
> +/**
> + * lsm_bpf_map_alloc - allocate a composite bpf_map blob
> + * @map: the bpf_map that needs a blob
> + *
> + * Allocate the bpf_map blob for all the modules
> + *
> + * Returns 0, or -ENOMEM if memory can't be allocated.
> + */
> +static int lsm_bpf_map_alloc(struct bpf_map *map)
> +{
> +	if (blob_sizes.lbs_bpf_map == 0) {
> +		map->security = NULL;
> +		return 0;
> +	}
> +
> +	map->security = kzalloc(blob_sizes.lbs_bpf_map, GFP_KERNEL);
> +	if (!map->security)
> +		return -ENOMEM;
> +
> +	return 0;
> +}

Casey suggested considering kmem_cache for the different BPF objects,
but my gut feeling is that none ofthe BPF objects are going to be
allocated with either enough frequency, or enough quantity, where a
simple kzalloc() wouldn't be sufficient, at least for now.  Thoughts
on this Blaise?

Assuming we stick with kazlloc() based allocation, please look at using
the lsm_blob_alloc() helper function as Song mentioned  As I'm writing
this I'm realizing there are a few allocatiors that aren't using the
helper, I need to fix those up ...

It's worth mentioning that the allocation scheme is an internal LSM
implementation detail, something we can change at any time with a small
patch, so I wouldn't stress too much about "Getting it Right" at this
point in time.

> @@ -5763,7 +5862,12 @@ int security_bpf_token_capable(const struct bpf_token *token, int cap)
>   */
>  void security_bpf_map_free(struct bpf_map *map)
>  {
> +	if (!map->security)
> +		return;
> +

We don't currently check if map->security is NULL in the current hook,
or the SELinux callback (it's not a common pattern for the LSM blobs),
did you run into a problem where the blob pointer was NULL?

The same comment applies to all three blob types.

>  	call_void_hook(bpf_map_free, map);
> +	kfree(map->security);
> +	map->security = NULL;
>  }
>  
>  /**

--
paul-moore.com