From: "Günther Noack" <gnoack@google.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: Jens Axboe <axboe@kernel.dk>,
Bryam Vargas <hexlabsecurity@proton.me>,
Paul Moore <paul@paul-moore.com>, Keith Busch <kbusch@kernel.org>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-security-module@vger.kernel.org,
Tingmao Wang <m@maowtm.org>
Subject: Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
Date: Wed, 17 Jun 2026 17:31:26 +0200 [thread overview]
Message-ID: <ajK9zjmNHGw81alz@google.com> (raw)
In-Reply-To: <20260617.aeNg7Aeseez4@digikod.net>
On Wed, Jun 17, 2026 at 04:16:38PM +0200, Mickaël Salaün wrote:
> As I explained in previous (private) reports, there is currently no
> io_uring hooks implemented for Landlock because there is no use for
> them.
>
> io_uring "bypass" was already mentioned to us two times in March but
> io_uring personality credential is not a Landlock bypass. The Landlock
> threat model is about enforcing restrictions when accessing new kernel
> resources, on a sandboxed subject. The credential identifies a set of
> access rights, so in the case of io_uring, the subject is inherited by
> the io_uring personality (i.e. the file descriptor). If a sandboxed
> task creates an io_uring personality, it will be sandboxed with the same
> restrictions, which is BTW an interesting property (e.g. pass a
> restricted io_uring FD to processes)
Remark on the side: We have previously received bug reports due to
io_uring using different credentials, but this report is not about that.
Instead, it is about the block device "discard" operation, which is
accessible through both (a) the ioctl() interface and (b) an io_uring
interface. The report is, in my reading, about the fact that the access
through (a) can be blocked with Landlock, while the access through (b)
can not be blocked through Landlock. (See the other answer I sent.)
But either way, as you are also saying here, we should probably document
better what the threat model for Landlock is, so that security
researchers (and AI models) can refer to that. It'll result in less
work for everyone.
I opened https://github.com/landlock-lsm/linux/issues/64 to track it and
collected some notes.
—Günther
next prev parent reply other threads:[~2026-06-17 15:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 20:16 Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD Bryam Vargas
2026-06-16 20:36 ` Jens Axboe
2026-06-17 2:25 ` Bryam Vargas
2026-06-17 2:44 ` Jens Axboe
2026-06-17 14:16 ` Mickaël Salaün
2026-06-17 14:56 ` Jens Axboe
2026-06-17 15:31 ` Günther Noack [this message]
2026-06-17 9:47 ` Günther Noack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ajK9zjmNHGw81alz@google.com \
--to=gnoack@google.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=hexlabsecurity@proton.me \
--cc=kbusch@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=m@maowtm.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox