Re: [PATCH v2] lsm,selinux: Add LSM blob support for BPF objects
From: Paul Moore <paul@paul-moore.com>
Date: 2025-08-07 01:44:25
Also in:
lkml, selinux
On Jul 22, 2025 Blaise Boscaccy [off-list ref] 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 <redacted> --- 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 ...
quoted hunk ↗ jump to hunk
@@ -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