[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <df2ecc560256f98a4fddf66529b72d38.paul@paul-moore.com>
Date: Mon, 06 Nov 2023 00:01:20 -0500
From: Paul Moore <paul@...l-moore.com>
To: Andrii Nakryiko <andrii@...nel.org>, <bpf@...r.kernel.org>, <netdev@...r.kernel.org>, <brauner@...nel.org>
Cc: <linux-fsdevel@...r.kernel.org>, <linux-security-module@...r.kernel.org>, <keescook@...omium.org>, <kernel-team@...a.com>, <sargun@...gun.me>
Subject: Re: [PATCH v9 10/17] bpf,lsm: refactor bpf_map_alloc/bpf_map_free LSM hooks
On Nov 3, 2023 Andrii Nakryiko <andrii@...nel.org> wrote:
>
> Similarly to bpf_prog_alloc LSM hook, rename and extend bpf_map_alloc
> hook into bpf_map_create, taking not just struct bpf_map, but also
> bpf_attr and bpf_token, to give a fuller context to LSMs.
>
> Unlike bpf_prog_alloc, there is no need to move the hook around, as it
> currently is firing right before allocating BPF map ID and FD, which
> seems to be a sweet spot.
>
> But like bpf_prog_alloc/bpf_prog_free combo, make sure that bpf_map_free
> LSM hook is called even if bpf_map_create hook returned error, as if few
> LSMs are combined together it could be that one LSM successfully
> allocated security blob for its needs, while subsequent LSM rejected BPF
> map creation. The former LSM would still need to free up LSM blob, so we
> need to ensure security_bpf_map_free() is called regardless of the
> outcome.
>
> Signed-off-by: Andrii Nakryiko <andrii@...nel.org>
> ---
> include/linux/lsm_hook_defs.h | 5 +++--
> include/linux/security.h | 6 ++++--
> kernel/bpf/bpf_lsm.c | 6 +++---
> kernel/bpf/syscall.c | 4 ++--
> security/security.c | 16 ++++++++++------
> security/selinux/hooks.c | 7 ++++---
> 6 files changed, 26 insertions(+), 18 deletions(-)
Acked-by: Paul Moore <paul@...l-moore.com>
--
paul-moore.com
Powered by blists - more mailing lists