Restrict the uring_cmd command multiplexer?

[gnoack]

file->f_op->uring_cmd is a generic command multiplexer through which files can implement file-specific commands.

This is similar to ioctl(2) in that sense, although the command numbers have a different namespace.
We should maybe restrict that, similarly as we have done it for IOCTLs with LANDLOCK_ACCESS_FS_IOCTL_DEV.

This was brought up by Bryam Vargas in https://lore.kernel.org/all/20260616201633.275067-1-hexlabsecurity@proton.me/ (and the follow-up discussion). There can be overlaps between uring_cmd commands and IOCTL commands, as it was pointed out there for BLOCK_URING_CMD_DISCARD and ioctl(BLKDISCARD). In the case of such commands, it might be surprising that they are blocked when used through IOCTL but work when used through io_uring.

Another alternative approach would be to block the creation of an io_uring altogether, through a Landlock policy. That would be a coarser control, but maybe good enough for the start, for the majority of use cases?

[RazeLighter777]

file->f_op->uring_cmd is a generic command multiplexer through which files can implement file-specific commands.

This is similar to ioctl(2) in that sense, although the command numbers have a different namespace. We should maybe restrict that, similarly as we have done it for IOCTLs with LANDLOCK_ACCESS_FS_IOCTL_DEV.

This was brought up by Bryam Vargas in https://lore.kernel.org/all/20260616201633.275067-1-hexlabsecurity@proton.me/ (and the follow-up discussion). There can be overlaps between uring_cmd commands and IOCTL commands, as it was pointed out there for BLOCK_URING_CMD_DISCARD and ioctl(BLKDISCARD). In the case of such commands, it might be surprising that they are blocked when used through IOCTL but work when used through io_uring.

An important thing to note is that is requires giving access to the block device, both via DAC and the Landlock policy. Many policies grant /dev naively, but even then in practice the process would need the permissions to write to the raw block device.

So this can be worked around for now by users by just not allowing writes to those block devices until a proper fix. Or a seccomp filter.

So I don't consider this a hugely urgent gap.

Another alternative approach would be to block the creation of an io_uring altogether, through a Landlock policy. That would be a coarser control, but maybe good enough for the start, for the majority of use cases?

Are you proposing this as a broad handled_access_* access right? I worry about the number of userspace programs today that use io_uring for normal I/O, so restricting the creation of it would indeed be a course access right of limited utility. Especially some userspace programs that might be using languages with abstractions over their standard libraries io facilities, that may decide between io_uring and other backends for IO at runtime. So their program may work on kernels without io_uring and suddenly stop working when the language runtime decides to pick io_uring.

Given the large number of different io_uring operations, it would make more sense for me for Landlock to close this with a handled_perm access right [1], so the list of allowed io_uring related operations could be owned by the io_uring subsystem. This would reduce churn and trying to hit a moving target, as io_uring is one of those quickly developing subsystems (like bpf) getting new features and ops all the time.

[1] : https://lore.kernel.org/linux-security-module/20260527181127.879771-10-mic@digikod.net/

[gnoack]

An important thing to note is that is requires giving access to the block device, both via DAC and the Landlock policy. Many policies grant /dev naively, but even then in practice the process would need the permissions to write to the raw block device.

So this can be worked around for now by users by just not allowing writes to those block devices until a proper fix. Or a seccomp filter.

So I don't consider this a hugely urgent gap.

I agree that the overlap in this particular "block discard" operation (which is anyway privileged to users with write access to the block device) is not a very strong reason to prioritize this very urgently.

Another alternative approach would be to block the creation of an io_uring altogether, through a Landlock policy. That would be a coarser control, but maybe good enough for the start, for the majority of use cases?

Are you proposing this as a broad handled_access_* access right? I worry about the number of userspace programs today that use io_uring for normal I/O, so restricting the creation of it would indeed be a course access right of limited utility. Especially some userspace programs that might be using languages with abstractions over their standard libraries io facilities, that may decide between io_uring and other backends for IO at runtime. So their program may work on kernels without io_uring and suddenly stop working when the language runtime decides to pick io_uring.

Given the large number of different io_uring operations, it would make more sense for me for Landlock to close this with a handled_perm access right [1], so the list of allowed io_uring related operations could be owned by the io_uring subsystem. This would reduce churn and trying to hit a moving target, as io_uring is one of those quickly developing subsystems (like bpf) getting new features and ops all the time.

[1] : https://lore.kernel.org/linux-security-module/20260527181127.879771-10-mic@digikod.net/

I have admittedly underestimated the number of applications that already use io_uring; after researching a bit, it seems that it is particularly in use in databases and userspace file system implementations, and then a bunch of libraries (but I don't know how much these are being used). I do wonder to what extent such programs are falling back to normal filesystem operations, if io_uring is unavailable?

For the record, another practical reason why I personally think it is reasonable to disable io_uring for a process is because it has had a problematic security track record in the past (see https://en.wikipedia.org/wiki/Io_uring#Security) and is seeing very active feature development. (It is possible that this will stabilize at some point though.)

Regarding the types of access rights:

• For a restriction on a whole io_uring creation, I think a handled_perm right would be the right approach.
• For a restriction on individual io_uring operations, I think we'd have to see case by case? After all, I believe that the normal file system operations through io_uring are already correctly restricted through Landlock, because they call the appropriate LSM hooks. (Apart from uring_cmd, do you know of other special kinds of operations that io_uring has introduced which would be necessary to restrict?)

[RazeLighter777]

An important thing to note is that is requires giving access to the block device, both via DAC and the Landlock policy. Many policies grant /dev naively, but even then in practice the process would need the permissions to write to the raw block device.
So this can be worked around for now by users by just not allowing writes to those block devices until a proper fix. Or a seccomp filter.
So I don't consider this a hugely urgent gap.

I agree that the overlap in this particular "block discard" operation (which is anyway privileged to users with write access to the block device) is not a very strong reason to prioritize this very urgently.

Another alternative approach would be to block the creation of an io_uring altogether, through a Landlock policy. That would be a coarser control, but maybe good enough for the start, for the majority of use cases?

Are you proposing this as a broad handled_access_* access right? I worry about the number of userspace programs today that use io_uring for normal I/O, so restricting the creation of it would indeed be a course access right of limited utility. Especially some userspace programs that might be using languages with abstractions over their standard libraries io facilities, that may decide between io_uring and other backends for IO at runtime. So their program may work on kernels without io_uring and suddenly stop working when the language runtime decides to pick io_uring.
Given the large number of different io_uring operations, it would make more sense for me for Landlock to close this with a handled_perm access right [1], so the list of allowed io_uring related operations could be owned by the io_uring subsystem. This would reduce churn and trying to hit a moving target, as io_uring is one of those quickly developing subsystems (like bpf) getting new features and ops all the time.
[1] : https://lore.kernel.org/linux-security-module/20260527181127.879771-10-mic@digikod.net/

I have admittedly underestimated the number of applications that already use io_uring; after researching a bit, it seems that it is particularly in use in databases and userspace file system implementations, and then a bunch of libraries (but I don't know how much these are being used). I do wonder to what extent such programs are falling back to normal filesystem operations, if io_uring is unavailable?

MariaDB is a clean example, defaults to innodb_linux_aio=auto, which prefers io_uring when it is available. [1]

Ceph will fall back to libaio if io_uring is enabled but not in the kernel. [2]

For the record, another practical reason why I personally think it is reasonable to disable io_uring for a process is because it has had a problematic security track record in the past (see https://en.wikipedia.org/wiki/Io_uring#Security) and is seeing very active feature development. (It is possible that this will stabilize at some point though.)

Regarding the types of access rights:

* For a restriction on a _whole_ io_uring creation, I think a `handled_perm` right would be the right approach.

* For a restriction on individual io_uring operations, I think we'd have to see case by case?  After all, I believe that the normal file system operations through io_uring are already correctly restricted through Landlock, because they call the appropriate LSM hooks.  (Apart from `uring_cmd`, do you know of other special kinds of operations that io_uring has introduced which would be necessary to restrict?)

IORING_OP_URING_CMD128 is the main one that has been missed thus far. Hasn't been brought up specifically, but is basically the 128 SQE byte twin of IORING_OP_URING_CMD and it would be a bug to close the IORING_OP_URING_CMD gap without IORING_OP_URING_CMD128.

A couple others jump out at me, but most all the ops are already handled and / or are access rights Landlock currently doesn't handle anyway.

IORING_OP_SPLICE seems like a possible exploit vector, especially with all the other syscall side exploitation with the DirtyFrag/DirtyCow that use the normal splice. (splice and vmsplice have been so exploited, Linus is seriously considering removing the normal zero-copy functionality of the splice/vmsplice system call and making it a pvread/pvwrite wrapper [3]). This goes through security_file_permission unless both of the ends are pipes.

IORING_OP_RECV_ZC seems to not have any LSM hooks in it's path. If we ever end up handling security_socket_recvmsg, this will be a problem since it never calls any LSM hook for some reason.

[1] : https://mariadb.com/docs/release-notes/community-server/old-releases/12.0/12.0.2
[2]: ceph/ceph@2268be9
[3]: https://lore.kernel.org/all/20260531010107.1953702-3-safinaskar@gmail.com/T/#u