Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD

[Jens Axboe <axboe@kernel.dk>]

On 6/17/26 8:16 AM, Micka?l Sala?n wrote:
> 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.

I think updating the documentation is a good idea. Most of these are AI
nonsense anyway, and it'd hopefully help if the documentation reflected
what you wrote above. Even if not, then at least when the next one of
these slop reports come in, the reply can be as simple as just linking
to the documentation.

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

Nice!

-- 
Jens Axboe