* [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
* Re: [RFC PATCH 1/2] landlock: fix TCP Fast Open connection bypass
From: Matthieu Buffet @ 2026-07-01 21:42 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
In-Reply-To: <20260626.taijohThood1@digikod.net>
Hi Mickaël,
On 6/26/2026 10:40 PM, Mickaël Salaün wrote:
> Thanks Matthieu, could you please rebase this serise on the master
> branch (especially on top of your UDP changes)?
Yes I hoped I could send it just in time before the UDP merge, but no
luck. Here is the patch with your feedback, and rebased on next over UDP.
Have a nice day!
--
Matthieu
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: David Windsor @ 2026-07-01 22:58 UTC (permalink / raw)
To: Paul Moore
Cc: Alexei Starovoitov, 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:
[...]
>
> 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 :)
>
Makes sense, I can do it while I'm fixing the remaining issue flagged
by sashiko.
I'll route the LSM preparation patch containing struct lsm_xattrs and
security_lsmxattr_add() through security and the kfunc and selftest
through bpf. Does that work for you?
Thanks,
David
^ 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 23:21 UTC (permalink / raw)
To: David Windsor
Cc: Alexei Starovoitov, 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: <CAEXv5_ig4P=wMoiy4h-TbZt-Wz-YBAs5k6R4szSSxr4C0kjCTw@mail.gmail.com>
On Wed, Jul 1, 2026 at 6:58 PM David Windsor <dwindsor@gmail.com> wrote:
> On Wed, Jul 1, 2026 at 8:55 AM Paul Moore <paul@paul-moore.com> wrote:
> [...]
> >
> > 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 :)
>
> Makes sense, I can do it while I'm fixing the remaining issue flagged
> by sashiko.
>
> I'll route the LSM preparation patch containing struct lsm_xattrs and
> security_lsmxattr_add() through security and the kfunc and selftest
> through bpf. Does that work for you?
Yep.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 23:32 UTC (permalink / raw)
To: Mickaël Salaün
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: <20260701.aeghohNoe3ek@digikod.net>
On Wed, Jul 1, 2026 at 5:28 PM Mickaël Salaün <mic@digikod.net> wrote:
> 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.
That is true for some LSM hooks, but not all of them. LSM hooks are
really just another name for the functions that compose parts of the
LSM framework API; it isn't always strictly about access control in
the kernel. We leverage the "hooks" for the LSM syscalls, we've
discussed "hooks" for implementing a common LSM namespace API, and
there have also been early efforts at LSM policy loading via "hooks".
> 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.
Once again, there have already been discussions about trying to build
a common API for that. I'd rather have us pick that up for an
in-kernel/kfunc users than treat Landlock as an exception. We're
trying to get rid of the exceptions in the LSM space.
> 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.
I think Casey's reply answers that question rather well.
--
paul-moore.com
^ permalink raw reply
* [PATCH v2] selftests/landlock: fix spelling error in fs_test comment
From: Wang Yan @ 2026-07-02 1:58 UTC (permalink / raw)
To: mic, gnoack, shuah
Cc: linux-security-module, linux-kselftest, linux-kernel, Wang Yan
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
* Re: [RFC PATCH 0/4] Introduce capable_noaudit
From: Christian Brauner @ 2026-07-02 7:41 UTC (permalink / raw)
To: cem
Cc: linux-fsdevel, jack, djwong, hch, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260626114533.102138-1-cem@kernel.org>
On 2026-06-26 13:45 +0200, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> In some cases - filesystems quota specifically here - we'd like to check
> for effective capabilities without issuing spurious audit messages and
> without the need to specify a namespace for that.
>
> This series introduce capable_noaudit() which has the same goal as
> capable() but without firing audit messages.
>
> Also, this updates both generic quota and xfs quota code to use that.
>
> The last patch unexports has_capability_noaudit() which was originally
> exported to be used in xfs but turns out it does not meet our needs.
>
> Note this is based on top of a current series I have to remove
> has_capability_noaudit() calls from xfs so the xfs patch won't
> apply cleanly without that series.
>
> If adding this helper is acceptable, I'll turn this into a non-rfc
> series with the required changes to apply properly.
>
> Comments? Flames?
Convert more, please.
^ permalink raw reply
* Re: [RFC PATCH 1/4] capabily: Add new capable_noaudit
From: Carlos Maiolino @ 2026-07-02 7:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, jack, djwong, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260629122939.GA21958@lst.de>
On Mon, Jun 29, 2026 at 02:29:39PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 26, 2026 at 01:45:20PM +0200, cem@kernel.org wrote:
> > +extern bool capable_noaudit(int cap);
>
> No need for the extern.
Indeed, I was just being consistent with the rest of the file :P
>
> Otherwise this does look nice an clean to me:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> But if the security folks don't like we can live with the more
> verbose version of it I guess.
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/4] Introduce capable_noaudit
From: Carlos Maiolino @ 2026-07-02 8:35 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-fsdevel, jack, djwong, hch, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260702-alufelgen-belag-tastatur-b666a49f7fc0@brauner>
On Thu, Jul 02, 2026 at 09:41:39AM +0200, Christian Brauner wrote:
> On 2026-06-26 13:45 +0200, cem@kernel.org wrote:
> > From: Carlos Maiolino <cem@kernel.org>
> >
> > In some cases - filesystems quota specifically here - we'd like to check
> > for effective capabilities without issuing spurious audit messages and
> > without the need to specify a namespace for that.
> >
> > This series introduce capable_noaudit() which has the same goal as
> > capable() but without firing audit messages.
> >
> > Also, this updates both generic quota and xfs quota code to use that.
> >
> > The last patch unexports has_capability_noaudit() which was originally
> > exported to be used in xfs but turns out it does not meet our needs.
> >
> > Note this is based on top of a current series I have to remove
> > has_capability_noaudit() calls from xfs so the xfs patch won't
> > apply cleanly without that series.
> >
> > If adding this helper is acceptable, I'll turn this into a non-rfc
> > series with the required changes to apply properly.
> >
> > Comments? Flames?
>
> Convert more, please.
>
Convert what? :) more callers from capable() to capable_noaudit()?
^ permalink raw reply
* Re: [PATCH v2] selftests/landlock: fix spelling error in fs_test comment
From: Günther Noack @ 2026-07-02 9:05 UTC (permalink / raw)
To: Wang Yan; +Cc: mic, shuah, linux-security-module, linux-kselftest, linux-kernel
In-Reply-To: <20260702015823.368529-1-wangyan01@kylinos.cn>
On Thu, Jul 02, 2026 at 09:58:23AM +0800, Wang Yan wrote:
> 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
>
Reviewed-by: Günther Noack <gnoack@google.com>
^ permalink raw reply
* [PATCH v3 0/5] Fix quota evasion on xfs and add capable_noaudit
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Christoph Hellwig, Serge E. Hallyn, Darrick J. Wong,
Dave Chinner, Eric Sandeen, linux-xfs, linux-fsdevel,
linux-security-module, linux-kernel
From: Carlos Maiolino <cem@kernel.org>
Hi there.
This is the (hopefully) final version of the series I've been working on
to fix a quota evasion issue on xfs. This bug has originally been
introduced by accident while turning off audit messages while checking
quota limits in xfs by replacing capable() calls by has_capability_noaudit().
This series concatenates both series I sent for xfs and capabilities
infrastructure as they are dependent.
The first patch fix the xfs bug in a way that makes it easily portable
to older LTS kernels.
From second patch and beyond, it adds a new helper for the capabilities
framework named capable_noaudit() which as the same semantics as
capable() but without generating audit messages.
The following patches then replaces both generic quota call to
capable() and properly update xfs code to use this new helper.
Last but not least this unexport has_capability_noaudit which had been
previously exported.
Giving this affects different subsystems, I think it would be easier to
pull everything from a single tree (as long as everything is properly
reviewed of course).
Serge, Honza, are you guys ok if I pull those patches and send them to
Linus through xfs tree so we don't need to split the series?
Christoph, this series moves back to pass the capable_noaudit() result
straight back to xfs_trans_alloc_ichange() instead of moving the
capability check into xfs_trans_dqresv() as Darrick was not in agreement
with that (patch unreviewed and open for comments).
Changelog from the last state of these patches:
Patch2: removed the redundant external classifier from the declaration
in include/linux/capability.h.
Serge, I kept your RwB here as the external is redundant, please
let me know if you are ok with it or not.
Patch4: Replace all ns_capable_noaudit() calls by capable_noaudit() and
keep the CAP_FOWNER (instead replacing it by SYS_RESOURCE)
Carlos Maiolino (5):
xfs: fix capability check in xfs
capability: Add new capable_noaudit
quota: Don't issue audit messages on quota enforcing
xfs: replace ns_capable_noaudit
capability: unexport has_capability_noaudit
fs/quota/dquot.c | 2 +-
fs/xfs/xfs_fsmap.c | 3 +--
fs/xfs/xfs_ioctl.c | 2 +-
fs/xfs/xfs_iops.c | 3 ++-
include/linux/capability.h | 5 +++++
kernel/capability.c | 18 +++++++++++++++++-
6 files changed, 27 insertions(+), 6 deletions(-)
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/5] xfs: fix capability check in xfs
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: stable, Jan Kara, Christoph Hellwig, Serge E. Hallyn,
Darrick J. Wong, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Dr. Thomas Orgis
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
An user reported a bug where he managed to evade group's quota
by changing a file's gid to a different group id the same user
belonged to, even though quotas were enforced on both gids and the
file's size was big enough to exceed the quota's hardlimit.
Commit eba0549bc7d1 replaced a capable() call by a
has_capability_noaudit() to prevent unnecessary selinux audit messages.
Turns out that both calls have slightly different semantics even though
their documentation seems similar. Where in a nutshell:
capable() - Tests the task's effective credentials
has_ns_capability_noaudit() - Tests the task's real credentials
This most of the time has no practical difference but in some cases like
changing attrs (specifically group id in this case) through a NFS client
this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively
bypassing quota accounting checks.
Using instead ns_capable_noaudit() should fix this issue and prevent
selinux audit messages.
This also fix the remaining calls to has_capability_noaudit()
Fixes: eba0549bc7d1 ("xfs: don't generate selinux audit messages for capability testing")
Cc: <stable@vger.kernel.org> # v5.18
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reported-by: Dr. Thomas Orgis <thomas.orgis@uni-hamburg.de>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
---
fs/xfs/xfs_fsmap.c | 2 +-
fs/xfs/xfs_ioctl.c | 2 +-
fs/xfs/xfs_iops.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c
index b6a3bc9f143c..7c79fbe0a74c 100644
--- a/fs/xfs/xfs_fsmap.c
+++ b/fs/xfs/xfs_fsmap.c
@@ -1175,7 +1175,7 @@ xfs_getfsmap(
return -EINVAL;
use_rmap = xfs_has_rmapbt(mp) &&
- has_capability_noaudit(current, CAP_SYS_ADMIN);
+ ns_capable_noaudit(&init_user_ns, CAP_SYS_ADMIN);
head->fmh_entries = 0;
/* Set up our device handlers. */
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 1b53701bebea..1a8af827dde1 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -647,7 +647,7 @@ xfs_ioctl_setattr_get_trans(
goto out_error;
error = xfs_trans_alloc_ichange(ip, NULL, NULL, pdqp,
- has_capability_noaudit(current, CAP_FOWNER), &tp);
+ ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
if (error)
goto out_error;
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 6339f4956ecb..205fe2dae732 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -835,7 +835,8 @@ xfs_setattr_nonsize(
}
error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
- has_capability_noaudit(current, CAP_FOWNER), &tp);
+ ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
+ &tp);
if (error)
goto out_dqrele;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/5] capability: Add new capable_noaudit
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Darrick J. Wong, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Christoph Hellwig, Serge Hallyn
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
In some situations (quota enforcement bypass in this case) we'd like to
check for a specific capability without triggering spurious audit
messages from security modules like selinux.
Add a new helper so we don't need to use ns_capable_noaudit() directly.
V3: remove the extern declaration
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
---
include/linux/capability.h | 5 +++++
kernel/capability.c | 17 +++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 37db92b3d6f8..f8532d92fcad 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -145,6 +145,7 @@ extern bool has_capability_noaudit(struct task_struct *t, int cap);
extern bool has_ns_capability_noaudit(struct task_struct *t,
struct user_namespace *ns, int cap);
extern bool capable(int cap);
+bool capable_noaudit(int cap);
extern bool ns_capable(struct user_namespace *ns, int cap);
extern bool ns_capable_noaudit(struct user_namespace *ns, int cap);
extern bool ns_capable_setid(struct user_namespace *ns, int cap);
@@ -167,6 +168,10 @@ static inline bool capable(int cap)
{
return true;
}
+static inline bool capable_noaudit(int cap)
+{
+ return true;
+}
static inline bool ns_capable(struct user_namespace *ns, int cap)
{
return true;
diff --git a/kernel/capability.c b/kernel/capability.c
index 829f49ae07b9..2c2d1e8300bd 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -416,6 +416,23 @@ bool capable(int cap)
return ns_capable(&init_user_ns, cap);
}
EXPORT_SYMBOL(capable);
+
+/**
+ * capable_noaudit - Determine if the current task has a superior
+ * capability in effect (unaudited).
+ * @cap: The capability to be tested for
+ *
+ * This is the same as capable(), except it uses CAP_OPT_NOAUDIT as to prevent
+ * issuing spurious audit messages.
+ *
+ * This sets PF_SUPERPRIV on the task if the capability is available on the
+ * assumption that it's about to be used.
+ */
+bool capable_noaudit(int cap)
+{
+ return ns_capable_noaudit(&init_user_ns, cap);
+}
+EXPORT_SYMBOL(capable_noaudit);
#endif /* CONFIG_MULTIUSER */
/**
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/5] quota: Don't issue audit messages on quota enforcing
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Serge E. Hallyn, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Darrick J. Wong, Christoph Hellwig
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
Calling capable() to determine if we can bypass quota enforcement or not
can trigger spurious audit messages. We don't really require it here so
just use the capable_noaudit() version.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
fs/quota/dquot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index 9850de3955d3..dab93422a57b 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -1308,7 +1308,7 @@ static int ignore_hardlimit(struct dquot *dquot)
{
struct mem_dqinfo *info = &sb_dqopt(dquot->dq_sb)->info[dquot->dq_id.type];
- return capable(CAP_SYS_RESOURCE) &&
+ return capable_noaudit(CAP_SYS_RESOURCE) &&
(info->dqi_format->qf_fmt_id != QFMT_VFS_OLD ||
!(info->dqi_flags & DQF_ROOT_SQUASH));
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3 4/5] xfs: replace ns_capable_noaudit
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Christoph Hellwig, Serge E. Hallyn, Darrick J. Wong,
Dave Chinner, Eric Sandeen, linux-xfs, linux-fsdevel,
linux-security-module, linux-kernel
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
Now that capable_noaudit() is available, we don't need to keep
using ns_capable_noaudit() and specifying the usernaspace every single
time.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
fs/xfs/xfs_fsmap.c | 3 +--
fs/xfs/xfs_ioctl.c | 2 +-
fs/xfs/xfs_iops.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c
index 7c79fbe0a74c..041bb2105ec6 100644
--- a/fs/xfs/xfs_fsmap.c
+++ b/fs/xfs/xfs_fsmap.c
@@ -1174,8 +1174,7 @@ xfs_getfsmap(
if (!xfs_getfsmap_check_keys(&head->fmh_keys[0], &head->fmh_keys[1]))
return -EINVAL;
- use_rmap = xfs_has_rmapbt(mp) &&
- ns_capable_noaudit(&init_user_ns, CAP_SYS_ADMIN);
+ use_rmap = xfs_has_rmapbt(mp) && capable_noaudit(CAP_SYS_ADMIN);
head->fmh_entries = 0;
/* Set up our device handlers. */
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 1a8af827dde1..374b488f0416 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -647,7 +647,7 @@ xfs_ioctl_setattr_get_trans(
goto out_error;
error = xfs_trans_alloc_ichange(ip, NULL, NULL, pdqp,
- ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
+ capable_noaudit(CAP_FOWNER), &tp);
if (error)
goto out_error;
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 205fe2dae732..ce9f8b8468fc 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -835,7 +835,7 @@ xfs_setattr_nonsize(
}
error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
- ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
+ capable_noaudit(CAP_FOWNER),
&tp);
if (error)
goto out_dqrele;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 5/5] capability: unexport has_capability_noaudit
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Serge E. Hallyn, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Darrick J. Wong, Christoph Hellwig
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
This has been originally exported to be used in xfs. Giving we are not
using it anymore, unexport for consistency.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
kernel/capability.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/capability.c b/kernel/capability.c
index 2c2d1e8300bd..3d0387fb93a3 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -326,7 +326,6 @@ bool has_capability_noaudit(struct task_struct *t, int cap)
{
return has_ns_capability_noaudit(t, &init_user_ns, cap);
}
-EXPORT_SYMBOL(has_capability_noaudit);
static bool ns_capable_common(struct user_namespace *ns,
int cap,
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-02 9:53 UTC (permalink / raw)
To: Paul Moore, Casey Schaufler
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: <CAHC9VhSYJPdn3Y+C1s8VExQ0DhV9Kg-NZiWhhOA657JeHDnzjQ@mail.gmail.com>
On Wed, Jul 01, 2026 at 07:32:57PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 5:28 PM Mickaël Salaün <mic@digikod.net> wrote:
> > 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.
>
> That is true for some LSM hooks, but not all of them. LSM hooks are
> really just another name for the functions that compose parts of the
> LSM framework API; it isn't always strictly about access control in
> the kernel.
That's why I wrote "in a nutshell". Concrete examples and the rationale
for such hooks would help.
> We leverage the "hooks" for the LSM syscalls, we've
> discussed "hooks" for implementing a common LSM namespace API, and
> there have also been early efforts at LSM policy loading via "hooks".
All that is doable, my question is: why a kfunc multiplexer? What are
the pros and cons? I only see disadvantages for now. Please, convince
us.
>
> > 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.
>
> Once again, there have already been discussions about trying to build
> a common API for that. I'd rather have us pick that up for an
> in-kernel/kfunc users than treat Landlock as an exception. We're
> trying to get rid of the exceptions in the LSM space.
I understand and I agree about the argument for dispatchers (e.g. access
control and state hooks) but not for multiplexers (i.e. which would be a
kfunc in this case).
How would look such multiplexer kfunc? Something like this?
union lsm_restrict_arg {
struct {
const struct landlock_rulest *ruleset,
int flags,
} landlock;
...?
};
int bpf_lsm_restrict_binprm(struct lsm_id target_lsm,
union lsm_restrict_arg multiplexed_generic_argument);
I don't see the point of such multiplexer. It adds complexity for no
gain, except maybe to sneak in new features by only extending the
argument types? What would be the value for eBPF users?
>
> > 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.
>
> I think Casey's reply answers that question rather well.
This was mainly about (access control/security) hooks, not multiplexer
interfaces.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-02 9:51 UTC (permalink / raw)
To: Casey Schaufler
Cc: Paul Moore, 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: <c9abd9ab-3379-47ab-ad41-79cec8f465c2@schaufler-ca.com>
On Wed, Jul 01, 2026 at 02:41:49PM -0700, Casey Schaufler wrote:
> 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?
From my point of view, your work has been, and continue to be, very
valuable and helped improve Linux security tremendously. Everyone agree
that no LSM should implement their own security hook. But that's not
the topic here. See
https://lore.kernel.org/all/20260701.aeghohNoe3ek@digikod.net/
> What
> if there's an LSM that does what Landlock does, but does it better?
Then the eBPF programs will use another kfunc, specific to the *new*
semantic of the other LSM.
> What if the Landlock sponsors decide to quit funding it? Or the maintainers
> get bored?
It is the same for any (kernel) interface: going through a multiplexer
would not help at all. Your argument is sound for security hooks, but
not here. Security (or access control) hooks make sense because they
identify a set of specific enforcement points in the kernel, and any LSM
can implement such hook to allow or deny the related operation. Other
hooks are useful to keep track of the kernel state. Again, see
https://lore.kernel.org/all/20260701.aeghohNoe3ek@digikod.net/
>
> I agree with Paul completely. Make the hooks available to any and all
> LSMs, or don't make them at all.
We don't need a security hook but a function call to one specific part
of the kernel with a very clear semantic that only make sense for one
subsystem (i.e. Landlock in this case). It's the same for other kfunc,
nothing special. The same way it would be a waste of time to implement
an in-kernel multiplexer for a set of unrelated operations, I really
don't see the value of adding a generic kfunc that might perform an
action according to an operation argument (i.e. multiplexer). Why
implementing an ioctl-like interface in the kernel? I'm open to
suggestions (and concrete proposal/examples) but so far I only heard
authoritative arguments that ignored most of my comments.
^ permalink raw reply
* Re: [PATCH v3 1/5] xfs: fix capability check in xfs
From: Christoph Hellwig @ 2026-07-02 10:30 UTC (permalink / raw)
To: cem
Cc: stable, Jan Kara, Christoph Hellwig, Serge E. Hallyn,
Darrick J. Wong, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Dr. Thomas Orgis
In-Reply-To: <20260702093324.127450-3-cem@kernel.org>
On Thu, Jul 02, 2026 at 11:33:17AM +0200, cem@kernel.org wrote:
> index 6339f4956ecb..205fe2dae732 100644
> --- a/fs/xfs/xfs_iops.c
> +++ b/fs/xfs/xfs_iops.c
> @@ -835,7 +835,8 @@ xfs_setattr_nonsize(
> }
>
> error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> - has_capability_noaudit(current, CAP_FOWNER), &tp);
> + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
Extra indentation and an overly long line caused by that here.
Otherwise looks good.
^ permalink raw reply
* Re: [PATCH v3 3/5] quota: Don't issue audit messages on quota enforcing
From: Jan Kara @ 2026-07-02 10:56 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Serge E. Hallyn, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Darrick J. Wong, Christoph Hellwig
In-Reply-To: <20260702093324.127450-7-cem@kernel.org>
On Thu 02-07-26 11:33:21, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> Calling capable() to determine if we can bypass quota enforcement or not
> can trigger spurious audit messages. We don't really require it here so
> just use the capable_noaudit() version.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: Eric Sandeen <sandeen@redhat.com>
> Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
> Cc: linux-xfs@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Makes sense. Feel free to add:
Acked-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/quota/dquot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> index 9850de3955d3..dab93422a57b 100644
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -1308,7 +1308,7 @@ static int ignore_hardlimit(struct dquot *dquot)
> {
> struct mem_dqinfo *info = &sb_dqopt(dquot->dq_sb)->info[dquot->dq_id.type];
>
> - return capable(CAP_SYS_RESOURCE) &&
> + return capable_noaudit(CAP_SYS_RESOURCE) &&
> (info->dqi_format->qf_fmt_id != QFMT_VFS_OLD ||
> !(info->dqi_flags & DQF_ROOT_SQUASH));
> }
> --
> 2.54.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v3 1/5] xfs: fix capability check in xfs
From: Carlos Maiolino @ 2026-07-02 11:17 UTC (permalink / raw)
To: Christoph Hellwig
Cc: stable, Jan Kara, Serge E. Hallyn, Darrick J. Wong, Dave Chinner,
Eric Sandeen, linux-xfs, linux-fsdevel, linux-security-module,
linux-kernel, Dr. Thomas Orgis
In-Reply-To: <20260702103052.GA6670@lst.de>
On Thu, Jul 02, 2026 at 12:30:52PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 02, 2026 at 11:33:17AM +0200, cem@kernel.org wrote:
> > index 6339f4956ecb..205fe2dae732 100644
> > --- a/fs/xfs/xfs_iops.c
> > +++ b/fs/xfs/xfs_iops.c
> > @@ -835,7 +835,8 @@ xfs_setattr_nonsize(
> > }
> >
> > error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> > - has_capability_noaudit(current, CAP_FOWNER), &tp);
> > + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
>
Thanks, I tried to keep the parameters aligned, but I can bring it one
tab back. Do you mind if I fix it at commit time if -unlikely- no other
change is required?
This is what it will look like:
error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
- has_capability_noaudit(current, CAP_FOWNER), &tp);
+ ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
+ &tp);
> Extra indentation and an overly long line caused by that here.
>
> Otherwise looks good.
>
^ permalink raw reply
* Re: [PATCH v3 1/5] xfs: fix capability check in xfs
From: Christoph Hellwig @ 2026-07-02 11:24 UTC (permalink / raw)
To: Carlos Maiolino
Cc: Christoph Hellwig, stable, Jan Kara, Serge E. Hallyn,
Darrick J. Wong, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Dr. Thomas Orgis
In-Reply-To: <akZITB_FDP1nl2_S@nidhogg.toxiclabs.cc>
On Thu, Jul 02, 2026 at 01:17:29PM +0200, Carlos Maiolino wrote:
> On Thu, Jul 02, 2026 at 12:30:52PM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 02, 2026 at 11:33:17AM +0200, cem@kernel.org wrote:
> > > index 6339f4956ecb..205fe2dae732 100644
> > > --- a/fs/xfs/xfs_iops.c
> > > +++ b/fs/xfs/xfs_iops.c
> > > @@ -835,7 +835,8 @@ xfs_setattr_nonsize(
> > > }
> > >
> > > error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> > > - has_capability_noaudit(current, CAP_FOWNER), &tp);
> > > + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
> >
>
> Thanks, I tried to keep the parameters aligned, but I can bring it one
> tab back. Do you mind if I fix it at commit time if -unlikely- no other
> change is required?
>
> This is what it will look like:
>
> error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> - has_capability_noaudit(current, CAP_FOWNER), &tp);
> + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
> + &tp);
This still adds an extra tab. Like much (but not all) of the kernel
we use two-tabs by default, which is also in the other two hinks. This
now adds a third. Just keep it as it was:
error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
^ permalink raw reply
* Re: [PATCH v3 1/5] xfs: fix capability check in xfs
From: Carlos Maiolino @ 2026-07-02 12:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: stable, Jan Kara, Serge E. Hallyn, Darrick J. Wong, Dave Chinner,
Eric Sandeen, linux-xfs, linux-fsdevel, linux-security-module,
linux-kernel, Dr. Thomas Orgis
In-Reply-To: <20260702112438.GA10565@lst.de>
On Thu, Jul 02, 2026 at 01:24:38PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 02, 2026 at 01:17:29PM +0200, Carlos Maiolino wrote:
> > On Thu, Jul 02, 2026 at 12:30:52PM +0200, Christoph Hellwig wrote:
> > > On Thu, Jul 02, 2026 at 11:33:17AM +0200, cem@kernel.org wrote:
> > > > index 6339f4956ecb..205fe2dae732 100644
> > > > --- a/fs/xfs/xfs_iops.c
> > > > +++ b/fs/xfs/xfs_iops.c
> > > > @@ -835,7 +835,8 @@ xfs_setattr_nonsize(
> > > > }
> > > >
> > > > error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> > > > - has_capability_noaudit(current, CAP_FOWNER), &tp);
> > > > + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
> > >
> >
> > Thanks, I tried to keep the parameters aligned, but I can bring it one
> > tab back. Do you mind if I fix it at commit time if -unlikely- no other
> > change is required?
> >
> > This is what it will look like:
> >
> > error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> > - has_capability_noaudit(current, CAP_FOWNER), &tp);
> > + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
> > + &tp);
>
> This still adds an extra tab. Like much (but not all) of the kernel
> we use two-tabs by default, which is also in the other two hinks. This
> now adds a third. Just keep it as it was:
>
> error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
>
>
Ok, will do!
^ permalink raw reply
* Re: [PATCH v3 1/5] xfs: fix capability check in xfs
From: Carlos Maiolino @ 2026-07-02 12:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: stable, Jan Kara, Serge E. Hallyn, Darrick J. Wong, Dave Chinner,
Eric Sandeen, linux-xfs, linux-fsdevel, linux-security-module,
linux-kernel, Dr. Thomas Orgis
In-Reply-To: <20260702112438.GA10565@lst.de>
> > + ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
> > + &tp);
>
> This still adds an extra tab. Like much (but not all) of the kernel
> we use two-tabs by default, which is also in the other two hinks. This
> now adds a third. Just keep it as it was:
>
> error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
> ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
>
>
FWIW, I also fixed these in the patch 4 which I had screwed up too :)
^ permalink raw reply
* Re: [RFC PATCH 0/4] Introduce capable_noaudit
From: Christian Brauner @ 2026-07-02 13:47 UTC (permalink / raw)
To: Carlos Maiolino
Cc: Christian Brauner, linux-fsdevel, jack, djwong, hch, serge,
linux-security-module, linux-kernel, linux-xfs
In-Reply-To: <akYimPrAcHlv7shR@nidhogg.toxiclabs.cc>
On 2026-07-02 10:35 +0200, Carlos Maiolino wrote:
> On Thu, Jul 02, 2026 at 09:41:39AM +0200, Christian Brauner wrote:
> > On 2026-06-26 13:45 +0200, cem@kernel.org wrote:
> > > From: Carlos Maiolino <cem@kernel.org>
> > >
> > > In some cases - filesystems quota specifically here - we'd like to check
> > > for effective capabilities without issuing spurious audit messages and
> > > without the need to specify a namespace for that.
> > >
> > > This series introduce capable_noaudit() which has the same goal as
> > > capable() but without firing audit messages.
> > >
> > > Also, this updates both generic quota and xfs quota code to use that.
> > >
> > > The last patch unexports has_capability_noaudit() which was originally
> > > exported to be used in xfs but turns out it does not meet our needs.
> > >
> > > Note this is based on top of a current series I have to remove
> > > has_capability_noaudit() calls from xfs so the xfs patch won't
> > > apply cleanly without that series.
> > >
> > > If adding this helper is acceptable, I'll turn this into a non-rfc
> > > series with the required changes to apply properly.
> > >
> > > Comments? Flames?
> >
> > Convert more, please.
> >
>
> Convert what? :) more callers from capable() to capable_noaudit()?
Yes, there's more code that should use the noaudit variant. Future
work...
^ 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