Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD

["Mickaël Salaün" <mic@digikod.net>]

On Tue, Jun 16, 2026 at 08:44:55PM -0600, Jens Axboe wrote:
> On 6/16/26 8:25 PM, Bryam Vargas wrote:
> > Thanks Jens ? noted, the fix belongs in Landlock. Micka?l has the full
> > report.
> 
> Indeed - and hence no need to bother anyone else with it by blasting it
> wide. I've already explained this multiple times, but on the private
> security list, when the occasional AI report comes in on things like
> this. Hence why it's a bit tiring to see the same stuff come across,
> once again.
> 
> For the landlock folks, I'd suggest taking a look at what hooks already
> exists (and existed, when landlock was merged) for selinux etc, that'd
> be a really good hint on the existing surface covered.

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)

A sandboxed process cannot create an io_uring personality that would
bypass its own restrictions, so there is no Landlock bypass.  Inheriting
or receiving a file descriptor is not restricted by Landlock because
these are operations from outside (or before) the sandbox.  If we want
to restrict them, we need to restrict the processes creating such file
descriptor.

Inherited or passed file descriptors are outside the Landlock threat
model because Landlock is only one part of the security policy when
(willingly) interacting with other processes.  In a nutshell, it's the
security capability model (where an object has some associated rights).
For instance, if a process willingly passes a file descriptor tied to a
secret file, then the receiving side can (and should be able to) read
it, being sandboxed with Landlock or not.  The scope of Landlock is to
drop ambient rights, but if an *unsandboxed* process is OK to pass a
sensitive resource, then that's a security architecture issue (i.e. a
confused deputy attack).

A nice side effect of this approach is that a process can sandbox itself
with a specific Landlock security policy and create an io_uring file
descriptor that will inherit the Landlock restrictions.  It can then
pass this FD to other processes with the guarantee that this FD will
only give access to resources allowed by the Landlock policy.

Landlock could implement the security_uring_sqpoll() hook, but for now
the use case is not clear to me.  We are working on controling socket
creation according to they properties and I think the same approach
would be useful for IO_URING:
https://lore.kernel.org/r/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com

I agree that this might be confusing and I plan to improve Landlock
documentation to make this clear and simpler for AI to take into
account.

BTW, we also have an opened issue to add io_uring tests:
https://github.com/landlock-lsm/linux/issues/23

Regards,
 Mickaël