* [PATCH v2 2/2] selftests/landlock: Add test for TCP fast open
From: Matthieu Buffet @ 2026-07-01 21:46 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, linux-security-module,
Mikhail Ivanov, Paul Moore, Eric Dumazet, Neal Cardwell,
linux-kernel, netdev, Matthieu Buffet
In-Reply-To: <20260701214628.33319-1-matthieu@buffet.re>
Enforce that TCP Fast Open is controlled by
LANDLOCK_ACCESS_NET_CONNECT_TCP. Semantics of connect() and
sendmsg(MSG_FASTOPEN) should be identical from Landlock's perspective.
Also enforce error code consistency, since UDP sockets ignore
the MSG_FASTOPEN flag while Unix sockets reject it.
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
tools/testing/selftests/landlock/net_test.c | 94 +++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
index 2ed1f76b7a8b..2e4dc5025b04 100644
--- a/tools/testing/selftests/landlock/net_test.c
+++ b/tools/testing/selftests/landlock/net_test.c
@@ -1281,6 +1281,100 @@ TEST_F(protocol, connect_unspec)
EXPECT_EQ(0, close(bind_fd));
}
+TEST_F(protocol, tcp_fastopen)
+{
+ const bool restricted = variant->sandbox == TCP_SANDBOX &&
+ variant->prot.type == SOCK_STREAM &&
+ (variant->prot.protocol == IPPROTO_TCP || variant->prot.protocol == IPPROTO_IP) &&
+ (variant->prot.domain == AF_INET || variant->prot.domain == AF_INET6);
+ const struct landlock_ruleset_attr ruleset_attr = {
+ .handled_access_net = LANDLOCK_ACCESS_NET_CONNECT_TCP,
+ };
+ int bind_fd, client_fd, status;
+ char buf;
+ pid_t child;
+
+ bind_fd = socket_variant(&self->srv0);
+ ASSERT_LE(0, bind_fd);
+ EXPECT_EQ(0, bind_variant(bind_fd, &self->srv0));
+ if (self->srv0.protocol.type == SOCK_STREAM)
+ EXPECT_EQ(0, listen(bind_fd, backlog));
+
+ child = fork();
+ ASSERT_LE(0, child);
+ if (child == 0) {
+ int connect_fd, ret;
+
+ /* Closes listening socket for the child. */
+ EXPECT_EQ(0, close(bind_fd));
+
+ connect_fd = socket_variant(&self->srv0);
+ ASSERT_LE(0, connect_fd);
+
+ if (variant->sandbox == TCP_SANDBOX) {
+ const int ruleset_fd = landlock_create_ruleset(
+ &ruleset_attr, sizeof(ruleset_attr), 0);
+ ASSERT_LE(0, ruleset_fd);
+
+ enforce_ruleset(_metadata, ruleset_fd);
+ EXPECT_EQ(0, close(ruleset_fd));
+ }
+
+ /* Fast Open with no address. */
+ ret = sendto_variant(connect_fd, NULL, NULL, 0, MSG_FASTOPEN);
+ if (self->srv0.protocol.domain == AF_UNIX) {
+ EXPECT_EQ(-ENOTCONN, ret);
+ } else if (self->srv0.protocol.type == SOCK_DGRAM) {
+ EXPECT_EQ(-EDESTADDRREQ, ret);
+ } else {
+ EXPECT_EQ(-EINVAL, ret);
+ }
+
+ /* Fast Open to a denied address. */
+ ret = sendto_variant(connect_fd, &self->srv0, "A", 1, MSG_FASTOPEN);
+ if (restricted) {
+ EXPECT_EQ(-EACCES, ret);
+ } else if (self->srv0.protocol.domain == AF_UNIX &&
+ self->srv0.protocol.type == SOCK_STREAM) {
+ EXPECT_EQ(-EOPNOTSUPP, ret);
+ } else {
+ EXPECT_EQ(0, ret);
+ }
+
+ EXPECT_EQ(0, close(connect_fd));
+ _exit(_metadata->exit_code);
+ return;
+ }
+
+ client_fd = bind_fd;
+ if (!restricted && self->srv0.protocol.type == SOCK_STREAM &&
+ self->srv0.protocol.domain != AF_UNIX) {
+ client_fd = accept(bind_fd, NULL, 0);
+ ASSERT_LE(0, client_fd);
+ }
+
+ if (restricted) {
+ EXPECT_EQ(-1, read(client_fd, &buf, 1));
+ EXPECT_EQ(ENOTCONN, errno);
+ } else if (self->srv0.protocol.domain == AF_UNIX &&
+ self->srv0.protocol.type == SOCK_STREAM) {
+ EXPECT_EQ(-1, read(client_fd, &buf, 1));
+ EXPECT_EQ(EINVAL, errno);
+ } else {
+ EXPECT_EQ(1, read(client_fd, &buf, 1));
+ EXPECT_EQ('A', buf);
+ }
+
+ EXPECT_EQ(child, waitpid(child, &status, 0));
+ EXPECT_EQ(1, WIFEXITED(status));
+ EXPECT_EQ(EXIT_SUCCESS, WEXITSTATUS(status));
+
+ if (client_fd != bind_fd)
+ EXPECT_LE(0, close(client_fd));
+
+ EXPECT_EQ(0, close(bind_fd));
+}
+
TEST_F(protocol, sendmsg_stream)
{
int srv0_fd, tmp_fd, client_fd, res;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] landlock: fix TCP Fast Open connection bypass
From: Matthieu Buffet @ 2026-07-01 21:46 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, linux-security-module,
Mikhail Ivanov, Paul Moore, Eric Dumazet, Neal Cardwell,
linux-kernel, netdev, Matthieu Buffet
In-Reply-To: <c21cf4f3-6c21-4170-b578-13c1bfd48b87@buffet.re>
The documentation of the socket_connect() LSM hook states that it
controls connecting a socket to a remote address. It has not been the
case since the addition of TCP Fast Open (RFC 7413) support, which allows
opening a TCP connection (thus, setting a socket's destination address)
via the MSG_FASTOPEN flag passed to sendto()/sendmsg()/sendmmsg(). The
problem then got duplicated into MPTCP.
Landlock did not take it into account when its TCP support was added,
leaving a bypass of TCP connect policy.
Ideally a call to the LSM hook would be added in the fastopen code path,
in order to fix this generically. But connect() hooks are designed to run
with the socket locked, unlike sendmsg() hooks.
Closes: https://github.com/landlock-lsm/linux/issues/41
Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
security/landlock/net.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/security/landlock/net.c b/security/landlock/net.c
index cbff59ec3aba..46c17116fcf4 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -351,6 +351,14 @@ static int hook_socket_sendmsg(struct socket *const sock,
access_mask_t access_request;
int ret = 0;
+ if ((msg->msg_flags & MSG_FASTOPEN) && address && sk_is_tcp(sock->sk)) {
+ ret = current_check_access_socket(
+ sock, address, addrlen, LANDLOCK_ACCESS_NET_CONNECT_TCP,
+ true);
+ if (ret != 0)
+ return ret;
+ }
+
if (sk_is_udp(sock->sk))
access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
else
--
2.47.3
^ permalink raw reply related
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Casey Schaufler @ 2026-07-01 21:41 UTC (permalink / raw)
To: Paul Moore, Justin Suess
Cc: Mickaël Salaün, ast, daniel, kpsingh, john.fastabend,
andrii, viro, brauner, kees, gnoack, jack, jmorris, serge, song,
yonghong.song, martin.lau, m, eddyz87, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler, Casey Schaufler
In-Reply-To: <CAHC9VhTQtHPFGqu58EaFqMobV3LCcTsdzYfxy568P8mU769TMg@mail.gmail.com>
On 7/1/2026 1:02 PM, Paul Moore wrote:
> ...
>
>> Each LSM calls this once to register its sets. Because registration goes
>> through the framework, the framework gets to decide whether to actually
>> register them so you could, for example, run an LSM while explicitly
>> opting its BPF kfuncs out. (something that should be done at the LSM
>> framework level).
> I'm not opposed to the LSM supporting a set of kfuncs, see my comments
> in other threads, but we should treat these kfuncs just as we treat
> other LSM hooks today because that is what they are: LSM hooks that
> happened to be called from within a BPF program.
As someone who has been working to get the SELinux specific assumptions
out of the LSM framework for the past 15 years the notion of adding
Landlock specific interfaces makes me want to cry. Is it really that
difficult to understand that 5 or 10 years from now something is going
to come along that makes any LSM specific interface a nightmare? What
if there's an LSM that does what Landlock does, but does it better?
What if the Landlock sponsors decide to quit funding it? Or the maintainers
get bored?
I agree with Paul completely. Make the hooks available to any and all
LSMs, or don't make them at all.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 21:28 UTC (permalink / raw)
To: Paul Moore
Cc: Justin Suess, ast, daniel, kpsingh, john.fastabend, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <CAHC9VhTQtHPFGqu58EaFqMobV3LCcTsdzYfxy568P8mU769TMg@mail.gmail.com>
On Wed, Jul 01, 2026 at 04:02:36PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> > > On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > > > from accessing unstable internal Landlock fields.
> > > > > > > >
> > > > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > > > function as examples.
> > > > >
> > > > > This patch series is not about the LSM framework, only about Landlock
> > > > > and its specific model and use case. Landlock using some of the LSM API
> > > > > is not relevant here.
> > > >
> > > > Based on a quick look the patchset enables BPF programs to call
> > > > directly into Landlock. For the same reason we discourage other parts
> > > > of the kernel to call directly into individual LSMs, we want to
> > > > discourage BPF programs from calling directly into individual LSMs.
> > >
> > > We're OK for a dedicated kfunc to call directly into Landlock (with a
> > > tailored interface). Landlock is designed around its syscall interfaces
> > > (well documented, tailored, tested), and this would be a new user of
> > > almost the same UAPI.
> >
> > Paul, Mickaël,
> >
> > I think there's a cleaner way to resolve this.
> >
> > First, walking back my earlier email: I was wrong saying that we need to call
> > into security/security.c to check whether Landlock is enabled. Landlock's
> > init only runs when it's in the active lsm= list, so I can just test
> > landlock_initialized directly. There's no per-invocation reason to route
> > through the LSM framework for that.
>
> The landlock_initialized flag is not really a LSM framework API, that
> is still Landlock specific which is something we try hard to avoid.
>
> > Rather than routing each kfunc *invocation* through a security/security.c
> > wrapper, I think the right place for the framework to be involved is
> > *registration*: have the LSM framework own registration of an LSM's
> > kfunc sets, e.g.
> >
> > int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
> > const struct btf_kfunc_id_set *kset);
>
> That implies a set of LSM kfunc APIs which Alexei has been deadset
> against (see other ongoing threads).
>
> > Each LSM calls this once to register its sets. Because registration goes
> > through the framework, the framework gets to decide whether to actually
> > register them so you could, for example, run an LSM while explicitly
> > opting its BPF kfuncs out. (something that should be done at the LSM
> > framework level).
>
> I'm not opposed to the LSM supporting a set of kfuncs, see my comments
> in other threads, but we should treat these kfuncs just as we treat
> other LSM hooks today because that is what they are: LSM hooks that
> happened to be called from within a BPF program.
What an LSM hook is or should be is the crux of the misunderstanding. I
explained my point of view here:
https://lore.kernel.org/all/20260701.jei4Paej3zen@digikod.net/
LSM hooks make sense because they are designed for a specific subsystem
(the caller) and their goal is to return an access decision or to keep
up-to-date related states, which means that their API is designed for
the caller, with its own types and specificities, not the other way
around. This case is different, the kfunc is strongly typed and tied to
the Landlock (subsystem) semantic with an API defined by and for
Landlock. I don't think a multiplexer would be a good idea.
I'd try to explain better: in a nutshell, an LSM hook exposes a subset
of the context of the caller, for any access control system to be able
to make a decision. It makes sense to have such dispatcher because the
callees must adapt to the caller's context, and then the API is tailored
to the caller, so even with several consumers, the API would ultimately
be the same. In the case of this kfunc, the callee is one specific
subsystem that happens to be Landlock. The caller asks a specific
subsystem to do something specific to this subsystem, not to ask all
potential access control systems to give a generic verdict to grant an
access or not. For this kfunc, the caller passes arguments which are
specific to the callee subsystem (e.g. a Landlock ruleset), not the
other way around. Every LSM has its own configuration, and it doesn't
make sense to somehow wrap these configurations with a common layer/API.
That's the same thing here.
Why not start with something simple that fits a use case now? If and
when another LSM will need a kfunc, then we'll have something concrete
to talk about.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 20:02 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, ast, daniel, kpsingh, john.fastabend,
andrii, viro, brauner, kees, gnoack, jack, jmorris, serge, song,
yonghong.song, martin.lau, m, eddyz87, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <akVvkA3kmlv_POsF@zenbox>
On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> > On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > > from accessing unstable internal Landlock fields.
> > > > > > >
> > > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > > function as examples.
> > > >
> > > > This patch series is not about the LSM framework, only about Landlock
> > > > and its specific model and use case. Landlock using some of the LSM API
> > > > is not relevant here.
> > >
> > > Based on a quick look the patchset enables BPF programs to call
> > > directly into Landlock. For the same reason we discourage other parts
> > > of the kernel to call directly into individual LSMs, we want to
> > > discourage BPF programs from calling directly into individual LSMs.
> >
> > We're OK for a dedicated kfunc to call directly into Landlock (with a
> > tailored interface). Landlock is designed around its syscall interfaces
> > (well documented, tailored, tested), and this would be a new user of
> > almost the same UAPI.
>
> Paul, Mickaël,
>
> I think there's a cleaner way to resolve this.
>
> First, walking back my earlier email: I was wrong saying that we need to call
> into security/security.c to check whether Landlock is enabled. Landlock's
> init only runs when it's in the active lsm= list, so I can just test
> landlock_initialized directly. There's no per-invocation reason to route
> through the LSM framework for that.
The landlock_initialized flag is not really a LSM framework API, that
is still Landlock specific which is something we try hard to avoid.
> Rather than routing each kfunc *invocation* through a security/security.c
> wrapper, I think the right place for the framework to be involved is
> *registration*: have the LSM framework own registration of an LSM's
> kfunc sets, e.g.
>
> int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
> const struct btf_kfunc_id_set *kset);
That implies a set of LSM kfunc APIs which Alexei has been deadset
against (see other ongoing threads).
> Each LSM calls this once to register its sets. Because registration goes
> through the framework, the framework gets to decide whether to actually
> register them so you could, for example, run an LSM while explicitly
> opting its BPF kfuncs out. (something that should be done at the LSM
> framework level).
I'm not opposed to the LSM supporting a set of kfuncs, see my comments
in other threads, but we should treat these kfuncs just as we treat
other LSM hooks today because that is what they are: LSM hooks that
happened to be called from within a BPF program.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 19:56 UTC (permalink / raw)
To: Mickaël Salaün
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.oTeikequi3ee@digikod.net>
On Wed, Jul 1, 2026 at 3:49 PM Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > from accessing unstable internal Landlock fields.
> > > > > >
> > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > function as examples.
> > >
> > > This patch series is not about the LSM framework, only about Landlock
> > > and its specific model and use case. Landlock using some of the LSM API
> > > is not relevant here.
> >
> > Based on a quick look the patchset enables BPF programs to call
> > directly into Landlock. For the same reason we discourage other parts
> > of the kernel to call directly into individual LSMs, we want to
> > discourage BPF programs from calling directly into individual LSMs.
>
> We're OK for a dedicated kfunc to call directly into Landlock (with a
> tailored interface). Landlock is designed around its syscall interfaces
> (well documented, tailored, tested), and this would be a new user of
> almost the same UAPI.
Larger issues exist beyond the suitability of Landlock's API; in fact
Landlock's API isn't really the issue as far as I'm concerned. The
issue is that we don't want the kernel, whether via C code or BPF
code, calling directly into individual LSMs. We don't even support
LSM A calling directly into LSM B. Any caller making a call into an
LSM really needs to do so through an LSM hook.
I'm not opposed to allowing BPF code to call into Landlock, it just
needs to do so through an LSM hook like everything else to date.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Justin Suess @ 2026-07-01 19:55 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, ast, daniel, kpsingh, john.fastabend, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.oTeikequi3ee@digikod.net>
On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > from accessing unstable internal Landlock fields.
> > > > > >
> > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > function as examples.
> > >
> > > This patch series is not about the LSM framework, only about Landlock
> > > and its specific model and use case. Landlock using some of the LSM API
> > > is not relevant here.
> >
> > Based on a quick look the patchset enables BPF programs to call
> > directly into Landlock. For the same reason we discourage other parts
> > of the kernel to call directly into individual LSMs, we want to
> > discourage BPF programs from calling directly into individual LSMs.
>
> We're OK for a dedicated kfunc to call directly into Landlock (with a
> tailored interface). Landlock is designed around its syscall interfaces
> (well documented, tailored, tested), and this would be a new user of
> almost the same UAPI.
Paul, Mickaël,
I think there's a cleaner way to resolve this.
First, walking back my earlier email: I was wrong saying that we need to call
into security/security.c to check whether Landlock is enabled. Landlock's
init only runs when it's in the active lsm= list, so I can just test
landlock_initialized directly. There's no per-invocation reason to route
through the LSM framework for that.
Rather than routing each kfunc *invocation* through a security/security.c
wrapper, I think the right place for the framework to be involved is
*registration*: have the LSM framework own registration of an LSM's
kfunc sets, e.g.
int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
const struct btf_kfunc_id_set *kset);
Each LSM calls this once to register its sets. Because registration goes
through the framework, the framework gets to decide whether to actually
register them so you could, for example, run an LSM while explicitly
opting its BPF kfuncs out. (something that should be done at the LSM
framework level).
This gives the framework control over kfunc enablement without an
pointless indirection on every call, and without making the kfunc
interface any more complex.
So this satisfies both sides of this argument:
Mickaël, this fits your suggestion to move them to security/landlock/bpf.c
and call directly into a Landlock function without needless abstraction.
We just register the landlock kfunc set with
security_register_lsm_kfunc_set, and that's it.
Paul, this way the LSM framework would have visibility into the
registration and enablement of the kfuncs that concern it.
Does this strike a reasonable balance?
Justin
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 19:49 UTC (permalink / raw)
To: Paul Moore
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <CAHC9VhRzZVUz8icZ2RD9OVvscJdZW3ivPERJLEkNi5poBeguxw@mail.gmail.com>
On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > from accessing unstable internal Landlock fields.
> > > > >
> > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > function as examples.
> >
> > This patch series is not about the LSM framework, only about Landlock
> > and its specific model and use case. Landlock using some of the LSM API
> > is not relevant here.
>
> Based on a quick look the patchset enables BPF programs to call
> directly into Landlock. For the same reason we discourage other parts
> of the kernel to call directly into individual LSMs, we want to
> discourage BPF programs from calling directly into individual LSMs.
We're OK for a dedicated kfunc to call directly into Landlock (with a
tailored interface). Landlock is designed around its syscall interfaces
(well documented, tailored, tested), and this would be a new user of
almost the same UAPI.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 18:38 UTC (permalink / raw)
To: Mickaël Salaün
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.jei4Paej3zen@digikod.net>
On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > from accessing unstable internal Landlock fields.
> > > >
> > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > function as examples.
>
> This patch series is not about the LSM framework, only about Landlock
> and its specific model and use case. Landlock using some of the LSM API
> is not relevant here.
Based on a quick look the patchset enables BPF programs to call
directly into Landlock. For the same reason we discourage other parts
of the kernel to call directly into individual LSMs, we want to
discourage BPF programs from calling directly into individual LSMs.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 18:34 UTC (permalink / raw)
To: Paul Moore, ast, daniel, kpsingh, john.fastabend
Cc: Justin Suess, andrii, viro, brauner, kees, gnoack, jack, jmorris,
serge, song, yonghong.song, martin.lau, m, eddyz87, sdf, skhan,
bpf, linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <CAHC9VhSjRcMr9+5dMkep_TPKduYdob-bZ73FLfXd_o2xiWwOSg@mail.gmail.com>
On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > from accessing unstable internal Landlock fields.
> > >
> > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > function as examples.
This patch series is not about the LSM framework, only about Landlock
and its specific model and use case. Landlock using some of the LSM API
is not relevant here.
> >
> > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > clear precedence for this. (BPF calling into specific LSM)
>
> The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> was still standalone, it wasn't until v6.9 that IMA and EVM became
> proper LSMs.
>
> > Kfuncs are explicitly marked as not being an ABI, and are more
> > flexible for later changes / deprecation etc. [1]
>
> The issue isn't so much the kfunc itself, it is what the kfunc
> *calls*. From what I saw in the proposed patch, the kfunc calls
> directly into Landlock instead of passing through the LSM framework,
> e.g. a function wrapper in security/security.c.
Yes, and I'm OK for this kfunc to call directly into a new public
Landlock function. There is no need to create a new class of LSM
wrapper.
LSM hooks make sense because they are designed for a specific subsystem
(the caller) and their goal is to return an access decision or to keep
up-to-date related states, which means that their API is designed for
the caller, with its own types and specificities, not the other way
around. This case is different, the kfunc is strongly typed and tied to
the Landlock (subsystem) semantic with an API defined by and for
Landlock. I don't think a multiplexer would be a good idea.
However, I agree with your layering concern, and it would make more
sense to move the Landlock-related kfuncs to security/landlock/bpf.c,
which is also the idiomatic way for subsystems to own their API.
Alexei, KP, what do you think?
>
> > LSM framework API can mean a lot of things. I assume you are meaning
> > like a pseudo-filesystem mounted interface that controls LSM?
> > Correct me if I'm wrong.
>
> My apologies, I should have been more clear. When I speak about the
> "LSM framework", I'm talking about the abstraction layer that provides
> the interface that the kernel and userspace uses to talk to individual
> LSMs. The LSM framework is analogous to the VFS layer/framework in
> that it provides a single API for a variety of underlying subsystems.
> While not 100% correct, you can think of it the LSM framework as being
> the functions/hooks defined in security/security.c.
This abstraction layer is useful and make sense for access control hooks
but it is not needed in this case, and it would only make the kfunc
interface more complex for no reason. If any other kernel subsystem
wants to add a kfunc, I think it should be reviewed with its purpose in
mind and a well defined use case.
>
> Does that help?
I think Justin is right, and with some minor changes this kfunc should
be good.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 18:33 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <akVbLGYyafZq_93v@zenbox>
On Wed, Jul 1, 2026 at 2:29 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > from accessing unstable internal Landlock fields.
> > > >
> > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > function as examples.
> > >
> > > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > > clear precedence for this. (BPF calling into specific LSM)
> >
> > The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> > was still standalone, it wasn't until v6.9 that IMA and EVM became
> > proper LSMs.
> >
> > > Kfuncs are explicitly marked as not being an ABI, and are more
> > > flexible for later changes / deprecation etc. [1]
> >
> > The issue isn't so much the kfunc itself, it is what the kfunc
> > *calls*. From what I saw in the proposed patch, the kfunc calls
> > directly into Landlock instead of passing through the LSM framework,
> > e.g. a function wrapper in security/security.c.
> >
> > > LSM framework API can mean a lot of things. I assume you are meaning
> > > like a pseudo-filesystem mounted interface that controls LSM?
> > > Correct me if I'm wrong.
> >
> > My apologies, I should have been more clear. When I speak about the
> > "LSM framework", I'm talking about the abstraction layer that provides
> > the interface that the kernel and userspace uses to talk to individual
> > LSMs. The LSM framework is analogous to the VFS layer/framework in
> > that it provides a single API for a variety of underlying subsystems.
> > While not 100% correct, you can think of it the LSM framework as being
> > the functions/hooks defined in security/security.c.
> >
> > Does that help?
>
> That does. security/security.c seems like a good place to enumerate the enabled
> LSMs and to check to make sure that Landlock is actually enabled both in the kernel
> build and that the Landlock LSM is up and running.
Yep.
> The above patch only checked if Landlock was compiled, when it should
> actually be checking if Landlock is actively enabled.
>
> So I will probably make a shim for it there that gates calls to
> Landlock.
Please keep in mind that the LSM framework API needs to be reasonably
generic. We've got some general guidance on adding new LSM hooks at
the link below:
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Justin Suess @ 2026-07-01 18:29 UTC (permalink / raw)
To: Paul Moore
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <CAHC9VhSjRcMr9+5dMkep_TPKduYdob-bZ73FLfXd_o2xiWwOSg@mail.gmail.com>
On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > from accessing unstable internal Landlock fields.
> > >
> > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > function as examples.
> >
> > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > clear precedence for this. (BPF calling into specific LSM)
>
> The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> was still standalone, it wasn't until v6.9 that IMA and EVM became
> proper LSMs.
>
> > Kfuncs are explicitly marked as not being an ABI, and are more
> > flexible for later changes / deprecation etc. [1]
>
> The issue isn't so much the kfunc itself, it is what the kfunc
> *calls*. From what I saw in the proposed patch, the kfunc calls
> directly into Landlock instead of passing through the LSM framework,
> e.g. a function wrapper in security/security.c.
>
> > LSM framework API can mean a lot of things. I assume you are meaning
> > like a pseudo-filesystem mounted interface that controls LSM?
> > Correct me if I'm wrong.
>
> My apologies, I should have been more clear. When I speak about the
> "LSM framework", I'm talking about the abstraction layer that provides
> the interface that the kernel and userspace uses to talk to individual
> LSMs. The LSM framework is analogous to the VFS layer/framework in
> that it provides a single API for a variety of underlying subsystems.
> While not 100% correct, you can think of it the LSM framework as being
> the functions/hooks defined in security/security.c.
>
> Does that help?
>
That does. security/security.c seems like a good place to enumerate the enabled
LSMs and to check to make sure that Landlock is actually enabled both in the kernel
build and that the Landlock LSM is up and running.
The above patch only checked if Landlock was compiled, when it should
actually be checking if Landlock is actively enabled.
So I will probably make a shim for it there that gates calls to
Landlock.
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-01 15:09 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Windsor, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Matt Bobrowski,
James Morris, Serge E . Hallyn, Casey Schaufler, Stephen Smalley,
Ondrej Mosnacek, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Alexander Viro, Christian Brauner, Jan Kara,
Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <CAHC9VhT37f5TwgksE_i0Yttpy3i7niBr6QrNVVmpwe_eGX428g@mail.gmail.com>
On Wed, Jul 1, 2026 at 8:55 AM Paul Moore <paul@paul-moore.com> wrote:
> On Wed, Jul 1, 2026 at 2:09 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Tue Jun 30, 2026 at 12:20 PM PDT, Paul Moore wrote:
> > >> +__bpf_kfunc int bpf_init_inode_xattr(struct lsm_xattrs *xattrs,
> > >> + const char *name__str,
> > >> + const struct bpf_dynptr *value_p)
> > >> +{
> > >> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
> > >> + size_t name_len;
> > >> + void *xattr_value;
> > >> + struct xattr *xattr;
> > >> + const void *value;
> > >> + u32 value_len;
> > >> +
> > >> + if (!xattrs || !xattrs->xattrs || !name__str)
> > >> + return -EINVAL;
> > >> + if (bpf_xattrs_used(xattrs) >= BPF_LSM_INODE_INIT_XATTRS)
> > >> + return -ENOSPC;
> > >> +
> > >> + name_len = strlen(name__str);
> > >> + if (name_len == 0 || name_len > XATTR_NAME_MAX)
> > >> + return -EINVAL;
> > >> + if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
> > >> + sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
> > >> + return -EPERM;
> > >> +
> > >> + value_len = __bpf_dynptr_size(value_ptr);
> > >> + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> > >> + return -EINVAL;
> > >> +
> > >> + value = __bpf_dynptr_data(value_ptr, value_len);
> > >> + if (!value)
> > >> + return -EINVAL;
> > >> +
> > >> + /* Combine xattr value + name into one allocation. */
> > >> + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOFS);
> > >> + if (!xattr_value)
> > >> + return -ENOMEM;
> > >> +
> > >> + memcpy(xattr_value, value, value_len);
> > >> + memcpy(xattr_value + value_len, name__str, name_len);
> > >> + ((char *)xattr_value)[value_len + name_len] = '\0';
> > >> +
> > >> + xattr = lsm_get_xattr_slot(xattrs);
> > >> + if (!xattr) {
> > >> + kfree(xattr_value);
> > >> + return -ENOSPC;
> > >> + }
> > >> +
> > >> + xattr->value = xattr_value;
> > >> + xattr->name = (const char *)xattr_value + value_len;
> > >> + xattr->value_len = value_len;
> > >> +
> > >> + return 0;
> > >> +}
> > >
> > > This is not a generic VFS function, it is a LSM specific function, it
> > > belongs under security/, please move the code as discussed previously.
> >
> > Paul,
> > Not quite. It's all about xattrs.
> > Having "struct lsm_xattrs" in the arguments doesn't make it lsm related.
> > You needs to study existing kfuncs and tracepoints.
> > A bunch of them have "*lsm*" in the arguments.
>
> Alexei,
>
> I'm sorry you don't understand the basics of the LSM concept, but
> please look at evm_inode_init_security(), xattr_dupval(), and
> selinux_inode_init_security() for some background. There should not
> be any usage of lsm_get_xattr_slot() or BPF_LSM_INODE_INIT_XATTRS
> outside of security/; you argued a similar idea to justify your NACK
> of Hornet, I'm simply applying the same logic here. We also have the
> very recent security issue caused by the BPF subsystem which failed to
> acknowledge that the admin disabled the BPF LSM and then walked all
> over kernel memory when it shouldn't. Moving LSM internals outside of
> the LSM creates an environment where flaws like this can go
> undetected.
>
> As I said previously, if you absolutely insist on the kfunc being in
> the VFS kfunc file, the LSM specific bits need to be abstracted out
> into an LSM function.
>
> kfunc bpf_init_inode_xattr(...)
> {
> /* sanity check params */
> if (!xattrs ...)
> return -EINVAL;
>
> /* get value/len from bpf dynptr */
>
> /* hook will check for LSM specific xattr count/limits, allocate,
> copy value*/
> rc = security_lsmxattr_add(xattrs, LSM_ID_BPF, value, value_len);
> if (rc)
> return rc;
> }
>
> David, if you like I can provide you a patch that implements the
> security_lsmxattr_add() hook above if you aren't comfortable writing
> that, but if you want to give it a shot that's all the better :)
One other thing - as this patchset is primarily LSM related, it needs
to be merged via the LSM tree. If Alexei can't tolerate the LSM tree
merging a minor BPF patch he can either choose to pull from an LSM
tree topic branch or we can merge the LSM infrastructure bits now and
he can merge the BPF changes when the LSM bits hit Linus' tree.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 0/6] selftests: fix multiple spelling errors across submodules
From: Sean Christopherson @ 2026-07-01 14:18 UTC (permalink / raw)
To: Wang Yan
Cc: Shuah Khan, Mickaël Salaün, Günther Noack,
linux-security-module, linux-kselftest, linux-kernel
In-Reply-To: <20260701123520.271580-1-wangyan01@kylinos.cn>
On Wed, Jul 01, 2026, Wang Yan wrote:
> This series fixes trivial spelling typos in comments across multiple
> selftests subdirectories. All changes are pure comment fixes, no
> functional or logical change to any test logic.
>
> Changes are split by subsystem for easier review and merging.
In the future, please send individual patches. Splitting the patches is nice,
but then bundling them in a single series that affects different maintainer
domains reintroduces the friction you're trying to avoid, especially since most
of us only got the one patch. E.g. I only received patch 4/6, which left me
wondering "what's in the other 5 patches?".
> Wang Yan (6):
> selftests/arm64: fix spelling errors in comments
> selftests/filesystems: fix spelling error in statmount test comment
> selftests/ftrace: fix spelling error in poll test comment
> selftests/kvm/x86: fix spelling error in xapic_ipi_test comment
> selftests/landlock: fix spelling error in fs_test comment
> selftests/powerpc/tm: fix spelling errors in comments
>
> tools/testing/selftests/arm64/gcs/libc-gcs.c | 2 +-
> tools/testing/selftests/arm64/pauth/pac.c | 2 +-
> tools/testing/selftests/filesystems/statmount/statmount_test.c | 2 +-
> tools/testing/selftests/ftrace/poll.c | 2 +-
> tools/testing/selftests/kvm/x86/xapic_ipi_test.c | 2 +-
> tools/testing/selftests/landlock/fs_test.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-signal-msr-resv.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-signal-stack.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-tar.c | 2 +-
> 9 files changed, 9 insertions(+), 9 deletions(-)
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 13:28 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <akUH13qbsEnJLgQu@zenbox>
On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > from accessing unstable internal Landlock fields.
> >
> > Generally speaking we don't want to provide APIs, either in-kernel or
> > at the userspace/kernel boundary, that are specific to a single LSM,
> > see the LSM syscalls or the security_current_getlsmprop_subj()
> > function as examples.
>
> I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> clear precedence for this. (BPF calling into specific LSM)
The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
was still standalone, it wasn't until v6.9 that IMA and EVM became
proper LSMs.
> Kfuncs are explicitly marked as not being an ABI, and are more
> flexible for later changes / deprecation etc. [1]
The issue isn't so much the kfunc itself, it is what the kfunc
*calls*. From what I saw in the proposed patch, the kfunc calls
directly into Landlock instead of passing through the LSM framework,
e.g. a function wrapper in security/security.c.
> LSM framework API can mean a lot of things. I assume you are meaning
> like a pseudo-filesystem mounted interface that controls LSM?
> Correct me if I'm wrong.
My apologies, I should have been more clear. When I speak about the
"LSM framework", I'm talking about the abstraction layer that provides
the interface that the kernel and userspace uses to talk to individual
LSMs. The LSM framework is analogous to the VFS layer/framework in
that it provides a single API for a variety of underlying subsystems.
While not 100% correct, you can think of it the LSM framework as being
the functions/hooks defined in security/security.c.
Does that help?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-01 12:55 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Windsor, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Matt Bobrowski,
James Morris, Serge E . Hallyn, Casey Schaufler, Stephen Smalley,
Ondrej Mosnacek, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Alexander Viro, Christian Brauner, Jan Kara,
Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <DJN0EPROS056.3RY0R6W1XZHNZ@gmail.com>
On Wed, Jul 1, 2026 at 2:09 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Tue Jun 30, 2026 at 12:20 PM PDT, Paul Moore wrote:
> >> +__bpf_kfunc int bpf_init_inode_xattr(struct lsm_xattrs *xattrs,
> >> + const char *name__str,
> >> + const struct bpf_dynptr *value_p)
> >> +{
> >> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
> >> + size_t name_len;
> >> + void *xattr_value;
> >> + struct xattr *xattr;
> >> + const void *value;
> >> + u32 value_len;
> >> +
> >> + if (!xattrs || !xattrs->xattrs || !name__str)
> >> + return -EINVAL;
> >> + if (bpf_xattrs_used(xattrs) >= BPF_LSM_INODE_INIT_XATTRS)
> >> + return -ENOSPC;
> >> +
> >> + name_len = strlen(name__str);
> >> + if (name_len == 0 || name_len > XATTR_NAME_MAX)
> >> + return -EINVAL;
> >> + if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
> >> + sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
> >> + return -EPERM;
> >> +
> >> + value_len = __bpf_dynptr_size(value_ptr);
> >> + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> >> + return -EINVAL;
> >> +
> >> + value = __bpf_dynptr_data(value_ptr, value_len);
> >> + if (!value)
> >> + return -EINVAL;
> >> +
> >> + /* Combine xattr value + name into one allocation. */
> >> + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOFS);
> >> + if (!xattr_value)
> >> + return -ENOMEM;
> >> +
> >> + memcpy(xattr_value, value, value_len);
> >> + memcpy(xattr_value + value_len, name__str, name_len);
> >> + ((char *)xattr_value)[value_len + name_len] = '\0';
> >> +
> >> + xattr = lsm_get_xattr_slot(xattrs);
> >> + if (!xattr) {
> >> + kfree(xattr_value);
> >> + return -ENOSPC;
> >> + }
> >> +
> >> + xattr->value = xattr_value;
> >> + xattr->name = (const char *)xattr_value + value_len;
> >> + xattr->value_len = value_len;
> >> +
> >> + return 0;
> >> +}
> >
> > This is not a generic VFS function, it is a LSM specific function, it
> > belongs under security/, please move the code as discussed previously.
>
> Paul,
> Not quite. It's all about xattrs.
> Having "struct lsm_xattrs" in the arguments doesn't make it lsm related.
> You needs to study existing kfuncs and tracepoints.
> A bunch of them have "*lsm*" in the arguments.
Alexei,
I'm sorry you don't understand the basics of the LSM concept, but
please look at evm_inode_init_security(), xattr_dupval(), and
selinux_inode_init_security() for some background. There should not
be any usage of lsm_get_xattr_slot() or BPF_LSM_INODE_INIT_XATTRS
outside of security/; you argued a similar idea to justify your NACK
of Hornet, I'm simply applying the same logic here. We also have the
very recent security issue caused by the BPF subsystem which failed to
acknowledge that the admin disabled the BPF LSM and then walked all
over kernel memory when it shouldn't. Moving LSM internals outside of
the LSM creates an environment where flaws like this can go
undetected.
As I said previously, if you absolutely insist on the kfunc being in
the VFS kfunc file, the LSM specific bits need to be abstracted out
into an LSM function.
kfunc bpf_init_inode_xattr(...)
{
/* sanity check params */
if (!xattrs ...)
return -EINVAL;
/* get value/len from bpf dynptr */
/* hook will check for LSM specific xattr count/limits, allocate,
copy value*/
rc = security_lsmxattr_add(xattrs, LSM_ID_BPF, value, value_len);
if (rc)
return rc;
}
David, if you like I can provide you a patch that implements the
security_lsmxattr_add() hook above if you aren't comfortable writing
that, but if you want to give it a shot that's all the better :)
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Justin Suess @ 2026-07-01 12:52 UTC (permalink / raw)
To: Paul Moore
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <CAHC9VhRfqSoM89WC6TdQHapUVQe8a18rW2c-F7+tu6EjM9EdCA@mail.gmail.com>
On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > from accessing unstable internal Landlock fields.
>
> Generally speaking we don't want to provide APIs, either in-kernel or
> at the userspace/kernel boundary, that are specific to a single LSM,
> see the LSM syscalls or the security_current_getlsmprop_subj()
> function as examples.
>
I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
clear precedence for this. (BPF calling into specific LSM)
Is this also discouraged now?
These IMA BPF functions are also helpers, which are more "permanent"
than the kfuncs like this patch proposes.
Kfuncs are explicitly marked as not being an ABI, and are more
flexible for later changes / deprecation etc. [1]
That was partially why I proposed this as a kfunc, and not a helper.
[1] : https://docs.ebpf.io/linux/concepts/kfuncs/
> Yes, Landlock does have its own syscalls, but those are
> "grandfathered" and not something I want to see emulated across other
> LSMs. If a BPF program wants to interact with a LSM, it should go
> through a LSM framework API.
>
LSM framework API can mean a lot of things. I assume you are meaning
like a pseudo-filesystem mounted interface that controls LSM?
Correct me if I'm wrong.
I'm a little unsure how this would work with the BPF model. Generally,
BPF relies on type checking and reference checking. Creating a weakly
typed securityfs / sysfs like interface would be very awkward for BPF to
use. Especially if it requires reading / writing files, or parsing
strings, it would be very hairy. It's the same problem with reading any
file from kernel space, it's almost always inadvisable.
Pseudo-fs is fantastic for userspace, (read and write is as simple as
echo and cat) but not fantastic when you are writing BPF programs.
But maybe this is a false diochotomy, I see no reason why the LSM
framework API couldn't have a strongly typed interface into BPF via
helpers / kfuncs. In that case, wouldn't these kfuncs be exactly that
LSM framework API? And there be some translation layer exposing them to
userspace using BTF type information -> pseudo fs? :)
BTF is not just for BPF!
Justin
> There have been some initial efforts to develop a LSM wide policy API
> for userspace, and while it was put on hold to sort out some namespace
> issues, we could move forward with an in-kernel API now. We don't
> have strict API stability guarantees for LSM hooks/APIs so we have
> some more freedom to do something now, even if it isn't perfect, and
> refine it at a later date.
>
> --
> paul-moore.com
^ permalink raw reply
* [PATCH 5/6] selftests/landlock: fix spelling error in fs_test comment
From: Wang Yan @ 2026-07-01 12:35 UTC (permalink / raw)
To: Shuah Khan, Mickaël Salaün, Günther Noack,
linux-security-module, linux-kselftest, linux-kernel
Cc: Wang Yan
In-Reply-To: <20260701123520.271580-1-wangyan01@kylinos.cn>
Fix typo "allowes" -> "allows" in Landlock filesystem test comment.
Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
---
tools/testing/selftests/landlock/fs_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 86e08aa6e0a7..e672089e9329 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -6927,7 +6927,7 @@ TEST_F_FORK(layout2_overlay, same_content_different_file)
ASSERT_EQ(0, test_open(path_entry, O_RDWR));
}
- /* Only allowes access to the merge hierarchy. */
+ /* Only allows access to the merge hierarchy. */
enforce_fs(_metadata, ACCESS_RW, layer5_merge_only);
/* Checks new accesses on lower layer. */
--
2.25.1
^ permalink raw reply related
* [PATCH 0/6] selftests: fix multiple spelling errors across submodules
From: Wang Yan @ 2026-07-01 12:35 UTC (permalink / raw)
To: Shuah Khan, Mickaël Salaün, Günther Noack,
linux-security-module
Cc: linux-kselftest, linux-kernel, Wang Yan
This series fixes trivial spelling typos in comments across multiple
selftests subdirectories. All changes are pure comment fixes, no
functional or logical change to any test logic.
Changes are split by subsystem for easier review and merging.
Please review.
Wang Yan (6):
selftests/arm64: fix spelling errors in comments
selftests/filesystems: fix spelling error in statmount test comment
selftests/ftrace: fix spelling error in poll test comment
selftests/kvm/x86: fix spelling error in xapic_ipi_test comment
selftests/landlock: fix spelling error in fs_test comment
selftests/powerpc/tm: fix spelling errors in comments
tools/testing/selftests/arm64/gcs/libc-gcs.c | 2 +-
tools/testing/selftests/arm64/pauth/pac.c | 2 +-
tools/testing/selftests/filesystems/statmount/statmount_test.c | 2 +-
tools/testing/selftests/ftrace/poll.c | 2 +-
tools/testing/selftests/kvm/x86/xapic_ipi_test.c | 2 +-
tools/testing/selftests/landlock/fs_test.c | 2 +-
tools/testing/selftests/powerpc/tm/tm-signal-msr-resv.c | 2 +-
tools/testing/selftests/powerpc/tm/tm-signal-stack.c | 2 +-
tools/testing/selftests/powerpc/tm/tm-tar.c | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 12:12 UTC (permalink / raw)
To: Mickaël Salaün, Justin Suess
Cc: ast, daniel, andrii, kpsingh, viro, brauner, kees, gnoack, jack,
jmorris, serge, song, yonghong.song, martin.lau, m, eddyz87,
john.fastabend, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.ze4eph1eKo7a@digikod.net>
On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > from accessing unstable internal Landlock fields.
Generally speaking we don't want to provide APIs, either in-kernel or
at the userspace/kernel boundary, that are specific to a single LSM,
see the LSM syscalls or the security_current_getlsmprop_subj()
function as examples.
Yes, Landlock does have its own syscalls, but those are
"grandfathered" and not something I want to see emulated across other
LSMs. If a BPF program wants to interact with a LSM, it should go
through a LSM framework API.
There have been some initial efforts to develop a LSM wide policy API
for userspace, and while it was put on hold to sort out some namespace
issues, we could move forward with an in-kernel API now. We don't
have strict API stability guarantees for LSM hooks/APIs so we have
some more freedom to do something now, even if it isn't perfect, and
refine it at a later date.
--
paul-moore.com
^ permalink raw reply
* linux-next: apparmor: ld.lld: error: undefined symbol: decompress_zstd
From: Tetsuo Handa @ 2026-07-01 11:46 UTC (permalink / raw)
To: Maxime Bélair, John Johansen; +Cc: linux-security-module
linux-next is failing to build, for decompress_zstd() is guarded by
CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y.
https://syzkaller.appspot.com/bug?id=71887a15323ee1c7728a72bf3bd6356263f4a10f
Please fix as soon as possible, for I'm asking syzbot to test my debug patches
using linux-next.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 10:59 UTC (permalink / raw)
To: Justin Suess
Cc: ast, daniel, andrii, kpsingh, paul, viro, brauner, kees, gnoack,
jack, jmorris, serge, song, yonghong.song, martin.lau, m, eddyz87,
john.fastabend, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260407200157.3874806-7-utilityemal77@gmail.com>
On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> Create 2 kfuncs exposing control over Landlock functionality to BPF
> callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> from accessing unstable internal Landlock fields.
>
> 1) bpf_landlock_put_ruleset releases a reference on a bpf_landlock_ruleset.
> This is properly passed to the verifier with the KF_RELEASE annotation.
>
> 2) bpf_landlock_restrict_binprm alters the pre-committed credentials in the
> linux_binprm struct, ensuring the program will start with the specified
> landlock ruleset. Normal domain inheritance, for existing and future
> domains apply as normal.
>
> To enable proper reference counting and destruction, a destructor is
> registered for the bpf_landlock_ruleset.
>
> Additionally, both kfuncs are restricted to LSM programs attached to
> bprm_creds_for_exec or bprm_creds_from_file, and only sleepable varients
> of these hooks. Landlock may block because a ruleset is protected by a
> lock, so both of the above kfuncs may sleep and are KF_SLEEPABLE.
>
> If RESTRICT_FLAGS_NO_NEW_PRIVS is set, and the task doesn't have
> CAP_SYS_ADMIN or is not already running with no_new_privs, we set the
> set_nnp_on_point_of_no_return to ensure that the next execution
> transition (but not the current one) will be subject to no_new_privs.
>
> Running task_set_no_new_privs directly is unsafe in this path, as a
> failed execution will result in a lingering side effect of no_new_privs
> being set on the original thread.
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> ---
> include/linux/bpf_lsm.h | 15 +++++
> kernel/bpf/bpf_lsm.c | 145 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 160 insertions(+)
>
> diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
> index 643809cc78c3..1fc019c0db44 100644
> --- a/include/linux/bpf_lsm.h
> +++ b/include/linux/bpf_lsm.h
> @@ -31,6 +31,21 @@ int bpf_lsm_verify_prog(struct bpf_verifier_log *vlog,
> bool bpf_lsm_is_sleepable_hook(u32 btf_id);
> bool bpf_lsm_is_trusted(const struct bpf_prog *prog);
>
> +/*
> + * Opaque type for BPF landlock ruleset. This is used to prevent BPF programs
> + * from directly accessing the landlock_ruleset structure, which is not designed
> + * for external use and may change in the future.
> + */
> +struct bpf_landlock_ruleset {};
> +BTF_ID_LIST_SINGLE(bpf_landlock_ruleset_btf_ids, struct, bpf_landlock_ruleset)
> +__bpf_kfunc void
> +bpf_landlock_put_ruleset(const struct bpf_landlock_ruleset *ruleset);
> +__bpf_kfunc int
> +bpf_landlock_restrict_binprm(struct linux_binprm *bprm,
> + const struct bpf_landlock_ruleset *ruleset,
> + u32 flags);
> +__bpf_kfunc void bpf_landlock_put_ruleset_dtor(void *ruleset);
> +
> static inline struct bpf_storage_blob *bpf_inode(
> const struct inode *inode)
> {
> diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> index 0c4a0c8e6f70..5da9950aa555 100644
> --- a/kernel/bpf/bpf_lsm.c
> +++ b/kernel/bpf/bpf_lsm.c
> @@ -16,6 +16,7 @@
> #include <linux/btf_ids.h>
> #include <linux/ima.h>
> #include <linux/bpf-cgroup.h>
> +#include <linux/landlock.h>
>
> /* For every LSM hook that allows attachment of BPF programs, declare a nop
> * function where a BPF program can be attached. Notably, we qualify each with
> @@ -447,3 +448,147 @@ int bpf_lsm_get_retval_range(const struct bpf_prog *prog,
> }
> return 0;
> }
> +
> +BTF_SET_START(bpf_landlock_kfunc_hooks)
> +BTF_ID(func, bpf_lsm_bprm_creds_for_exec)
> +BTF_ID(func, bpf_lsm_bprm_creds_from_file)
> +BTF_SET_END(bpf_landlock_kfunc_hooks)
> +
> +BTF_KFUNCS_START(bpf_landlock_kfunc_btf_ids)
> +BTF_ID_FLAGS(func, bpf_landlock_put_ruleset, KF_RELEASE | KF_SLEEPABLE)
> +BTF_ID_FLAGS(func, bpf_landlock_restrict_binprm, KF_SLEEPABLE)
> +BTF_KFUNCS_END(bpf_landlock_kfunc_btf_ids)
> +
> +BTF_ID_LIST(bpf_landlock_dtor_ids)
> +BTF_ID(struct, bpf_landlock_ruleset)
> +BTF_ID(func, bpf_landlock_put_ruleset_dtor)
> +
> +static int bpf_landlock_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
> +{
> + if (!btf_id_set8_contains(&bpf_landlock_kfunc_btf_ids, kfunc_id))
> + return 0;
> +
> + /* BPF_LSM_CGROUP programs run under classic RCU and cannot sleep. */
> + if (prog->expected_attach_type == BPF_LSM_CGROUP)
> + return -EACCES;
> +
> + if (!btf_id_set_contains(&bpf_landlock_kfunc_hooks,
> + prog->aux->attach_btf_id))
> + return -EACCES;
> +
> + return 0;
> +}
> +
> +static const struct btf_kfunc_id_set bpf_landlock_kfunc_set = {
> + .owner = THIS_MODULE,
> + .set = &bpf_landlock_kfunc_btf_ids,
> + .filter = bpf_landlock_kfunc_filter,
> +};
> +
> +static int __init bpf_landlock_kfunc_init(void)
> +{
> + const struct btf_id_dtor_kfunc bpf_landlock_dtors[] = {
> + {
> + .btf_id = bpf_landlock_dtor_ids[0],
> + .kfunc_btf_id = bpf_landlock_dtor_ids[1],
> + },
> + };
> + int ret;
> +
> + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM,
> + &bpf_landlock_kfunc_set);
> + if (ret)
> + return ret;
> +
> + return register_btf_id_dtor_kfuncs(bpf_landlock_dtors,
> + ARRAY_SIZE(bpf_landlock_dtors),
> + THIS_MODULE);
> +}
> +
> +late_initcall(bpf_landlock_kfunc_init);
> +
> +__bpf_kfunc_start_defs();
> +
> +#if IS_ENABLED(CONFIG_SECURITY_LANDLOCK)
> +
> +/**
> + * bpf_landlock_put_ruleset - put a Landlock ruleset
> + * @ruleset: Landlock ruleset to put
> + */
> +__bpf_kfunc void
> +bpf_landlock_put_ruleset(const struct bpf_landlock_ruleset *ruleset)
> +{
> + landlock_put_ruleset((struct landlock_ruleset *)ruleset);
> +}
> +
> +/**
> + * bpf_landlock_restrict_binprm - enforce a Landlock ruleset on exec credentials
> + * @bprm: execution context providing the prepared credentials to restrict
> + * @ruleset: Landlock ruleset to enforce, may be NULL only with
> + * LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF
> + * @flags: landlock_restrict_self() flags
> + *
> + * When @flags contains LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS, the request is
> + * staged through @bprm and committed only after exec reaches point-of-no-return.
> + * This guarantees that the resulting task cannot gain more privileges through
> + * later exec transitions, including when called from bprm_creds_from_file.
> + * The current execution is unaffected, and may escalate as usual until the next
> + * exec.
> + */
> +__bpf_kfunc int
> +bpf_landlock_restrict_binprm(struct linux_binprm *bprm,
> + const struct bpf_landlock_ruleset *ruleset,
> + u32 flags)
> +{
> + int err = landlock_restrict_cred_precheck(flags, false);
Landlock domain creation allocates memory with GFP_KERNEL_ACCOUNT, but
when called by eBPF, this should not be the case.
> +
> + if (err)
> + return err;
> +
> + err = landlock_restrict_cred(bprm->cred,
> + (struct landlock_ruleset *)ruleset,
> + flags);
> +
> + if (err)
> + return err;
> + /*
> + * Stage no_new_privs through @bprm so exec can honor it without
> + * mutating the current task before point-of-no-return.
> + */
> + if ((flags & LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS)
> + && !task_no_new_privs(current)
> + && !ns_capable_noaudit(current_user_ns(), CAP_SYS_ADMIN))
> + bprm->set_nnp_on_point_of_no_return = 1;
> +
> + return err;
> +}
> +
> +/* We define stubs for these to allow ebpf programs using landlock kfuncs to load
> + * even when CONFIG_SECURITY_LANDLOCK is not enabled.
> + */
> +#else /* IS_ENABLED(CONFIG_SECURITY_LANDLOCK) */
> +
> +__bpf_kfunc void
> +bpf_landlock_put_ruleset(const struct bpf_landlock_ruleset *ruleset)
> +{
> +}
> +
> +__bpf_kfunc int
> +bpf_landlock_restrict_binprm(struct linux_binprm *bprm,
> + const struct bpf_landlock_ruleset *ruleset,
> + u32 flags)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +#endif /* IS_ENABLED(CONFIG_SECURITY_LANDLOCK) */
> +
> +/* Destructor does nothing when Landlock is not enabled */
> +__bpf_kfunc void bpf_landlock_put_ruleset_dtor(void *ruleset)
> +{
> + bpf_landlock_put_ruleset(ruleset);
> +}
> +
> +CFI_NOSEAL(bpf_landlock_put_ruleset_dtor);
> +
> +__bpf_kfunc_end_defs();
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Alexei Starovoitov @ 2026-07-01 6:09 UTC (permalink / raw)
To: Paul Moore, David Windsor
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <CAHC9VhSYNF=_Tfe-D99rHy70EXQVr1ES0arxT09Bidey4zOFdg@mail.gmail.com>
On Tue Jun 30, 2026 at 12:20 PM PDT, Paul Moore wrote:
>> +__bpf_kfunc int bpf_init_inode_xattr(struct lsm_xattrs *xattrs,
>> + const char *name__str,
>> + const struct bpf_dynptr *value_p)
>> +{
>> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
>> + size_t name_len;
>> + void *xattr_value;
>> + struct xattr *xattr;
>> + const void *value;
>> + u32 value_len;
>> +
>> + if (!xattrs || !xattrs->xattrs || !name__str)
>> + return -EINVAL;
>> + if (bpf_xattrs_used(xattrs) >= BPF_LSM_INODE_INIT_XATTRS)
>> + return -ENOSPC;
>> +
>> + name_len = strlen(name__str);
>> + if (name_len == 0 || name_len > XATTR_NAME_MAX)
>> + return -EINVAL;
>> + if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
>> + sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
>> + return -EPERM;
>> +
>> + value_len = __bpf_dynptr_size(value_ptr);
>> + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
>> + return -EINVAL;
>> +
>> + value = __bpf_dynptr_data(value_ptr, value_len);
>> + if (!value)
>> + return -EINVAL;
>> +
>> + /* Combine xattr value + name into one allocation. */
>> + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOFS);
>> + if (!xattr_value)
>> + return -ENOMEM;
>> +
>> + memcpy(xattr_value, value, value_len);
>> + memcpy(xattr_value + value_len, name__str, name_len);
>> + ((char *)xattr_value)[value_len + name_len] = '\0';
>> +
>> + xattr = lsm_get_xattr_slot(xattrs);
>> + if (!xattr) {
>> + kfree(xattr_value);
>> + return -ENOSPC;
>> + }
>> +
>> + xattr->value = xattr_value;
>> + xattr->name = (const char *)xattr_value + value_len;
>> + xattr->value_len = value_len;
>> +
>> + return 0;
>> +}
>
> This is not a generic VFS function, it is a LSM specific function, it
> belongs under security/, please move the code as discussed previously.
Paul,
Not quite. It's all about xattrs.
Having "struct lsm_xattrs" in the arguments doesn't make it lsm related.
You needs to study existing kfuncs and tracepoints.
A bunch of them have "*lsm*" in the arguments.
All,
CI found issues, so this set needs another respin.
After that it's hopefully good to go.
David,
you're on the right track. The patchset is getting close.
Thank you for working on it.
^ permalink raw reply
* Re: [PATCH v3 stable/linux-6.12.y 0/3] Backport Fix incorrect overlayfs mmap() and mprotect() LSM access controls
From: Sasha Levin @ 2026-06-30 22:23 UTC (permalink / raw)
To: viro, brauner, jack, miklos, amir73il, paul, jmorris, serge,
stephen.smalley.work, omosnace, gregkh, bboscaccy, caixinchen1
Cc: Sasha Levin, linux-fsdevel, linux-kernel, linux-unionfs,
linux-security-module, selinux, bpf, stable, lujialin4
In-Reply-To: <20260629070338.578858-1-caixinchen1@huawei.com>
> Backport the patch series
> "Fix incorrect overlayfs mmap() and mprotect() LSM access controls" [1]
> to 6.12 lts
>
> Amir Goldstein (1):
> fs: constify file ptr in backing_file accessor helpers
>
> Paul Moore (2):
> lsm: add backing_file LSM hooks
> selinux: fix overlayfs mmap() and mprotect() access checks
All three patches are queued for 6.12, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-06-30 19:20 UTC (permalink / raw)
To: David Windsor
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <20260630183956.281293-3-dwindsor@gmail.com>
On Tue, Jun 30, 2026 at 2:40 PM David Windsor <dwindsor@gmail.com> wrote:
>
> Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> xattrs via the inode_init_security hook using lsm_get_xattr_slot(). The
> hook now passes its xattr state as a single struct lsm_xattrs object,
> which the kfunc takes directly.
>
> The kfunc is only usable from lsm/inode_init_security programs: no other
> hook exposes a struct lsm_xattrs argument, so the verifier rejects calls
> from elsewhere. Restrict the xattr names that may be set via this kfunc
> to the bpf.* namespace.
>
> BPF reserves BPF_LSM_INODE_INIT_XATTRS slots via lbs_xattr_count, and the
> kfunc enforces that BPF never consumes more slots than it reserved,
> returning -ENOSPC once the budget is exhausted.
>
> A previous attempt [1] required a kmalloc string output protocol for
> the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> provide xattrs for inode_init_security hook") [2], the xattr name is no
> longer allocated; it is a static constant.
>
> Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
> fs/bpf_fs_kfuncs.c | 79 +++++++++++++++++++++++++++++++++++++++++
> include/linux/bpf_lsm.h | 3 ++
> kernel/bpf/bpf_lsm.c | 1 +
> security/bpf/hooks.c | 1 +
> 4 files changed, 84 insertions(+)
>
> diff --git a/fs/bpf_fs_kfuncs.c b/fs/bpf_fs_kfuncs.c
> index 768aca2dc0f0..c4023c82f21e 100644
> --- a/fs/bpf_fs_kfuncs.c
> +++ b/fs/bpf_fs_kfuncs.c
> @@ -10,6 +10,7 @@
> #include <linux/fsnotify.h>
> #include <linux/file.h>
> #include <linux/kernfs.h>
> +#include <linux/lsm_hooks.h>
> #include <linux/mm.h>
> #include <linux/xattr.h>
>
> @@ -374,6 +375,83 @@ __bpf_kfunc struct inode *bpf_real_inode(struct dentry *dentry)
> return d_real_inode(dentry);
> }
>
> +static int bpf_xattrs_used(const struct lsm_xattrs *ctx)
> +{
> + const size_t prefix_len = sizeof(XATTR_BPF_LSM_SUFFIX) - 1;
> + unsigned int i, n = 0;
> +
> + for (i = 0; i < ctx->xattr_count; i++) {
> + const char *name = ctx->xattrs[i].name;
> +
> + if (name && !strncmp(name, XATTR_BPF_LSM_SUFFIX, prefix_len))
> + n++;
> + }
> + return n;
> +}
> +
> +/**
> + * bpf_init_inode_xattr - set an xattr on a new inode from inode_init_security
> + * @xattrs: inode_init_security xattr state from the hook context
> + * @name__str: xattr name (e.g., "bpf.file_label")
> + * @value_p: dynptr containing the xattr value
> + *
> + * Only callable from lsm/inode_init_security programs.
> + *
> + * Return: 0 on success, negative error on failure.
> + */
> +__bpf_kfunc int bpf_init_inode_xattr(struct lsm_xattrs *xattrs,
> + const char *name__str,
> + const struct bpf_dynptr *value_p)
> +{
> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
> + size_t name_len;
> + void *xattr_value;
> + struct xattr *xattr;
> + const void *value;
> + u32 value_len;
> +
> + if (!xattrs || !xattrs->xattrs || !name__str)
> + return -EINVAL;
> + if (bpf_xattrs_used(xattrs) >= BPF_LSM_INODE_INIT_XATTRS)
> + return -ENOSPC;
> +
> + name_len = strlen(name__str);
> + if (name_len == 0 || name_len > XATTR_NAME_MAX)
> + return -EINVAL;
> + if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
> + sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
> + return -EPERM;
> +
> + value_len = __bpf_dynptr_size(value_ptr);
> + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> + return -EINVAL;
> +
> + value = __bpf_dynptr_data(value_ptr, value_len);
> + if (!value)
> + return -EINVAL;
> +
> + /* Combine xattr value + name into one allocation. */
> + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOFS);
> + if (!xattr_value)
> + return -ENOMEM;
> +
> + memcpy(xattr_value, value, value_len);
> + memcpy(xattr_value + value_len, name__str, name_len);
> + ((char *)xattr_value)[value_len + name_len] = '\0';
> +
> + xattr = lsm_get_xattr_slot(xattrs);
> + if (!xattr) {
> + kfree(xattr_value);
> + return -ENOSPC;
> + }
> +
> + xattr->value = xattr_value;
> + xattr->name = (const char *)xattr_value + value_len;
> + xattr->value_len = value_len;
> +
> + return 0;
> +}
This is not a generic VFS function, it is a LSM specific function, it
belongs under security/, please move the code as discussed previously.
--
paul-moore.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox