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] [day] [month] [year] [list]

Message-ID: <875xfp4imx.fsf@microsoft.com>
Date: Fri, 18 Jul 2025 08:35:02 -0700
From: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
To: Paul Moore <paul@...l-moore.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>, 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

Paul Moore <paul@...l-moore.com> writes:

> 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?

Yeah, I agree, the number of allocations should be very low in
comparision to something like inodes. We are probably okay using kzalloc
forf the time being. 

>
> 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 ...

Will do.

>
> 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.

No real issues that I ran into. I was cribbing off the pattern used in
block devices. After taking a second look, it looks safe to remove that
check. I'll get that fixed in v2.

-blaise

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