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: <8d6e0d9d4bb99481d01500a7211e5119@paul-moore.com>
Date: Wed, 06 Aug 2025 21:44:22 -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>, Song Liu <song@...nel.org>, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v2] lsm,selinux: Add LSM blob support for BPF objects

On Jul 22, 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>
> ---
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ