Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD

["Günther Noack" <gnoack@google.com>]

Hello Bryam!

On Wed, Jun 17, 2026 at 11:02:41PM +0000, Bryam Vargas wrote:
> Thanks Günther, and thanks for filing #64.
> 
> Straight to your two questions:
> 
> 1. Block: you're right. blkdev_uring_cmd() has a single case, BLOCK_URING_CMD_DISCARD,
>    and the blkdev.h note that it's a separate number space is fair, so I'm not arguing
>    it should be a generic ioctl multiplexer. The "others, through other devices" are on
>    NVMe: the namespace char dev takes NVME_URING_CMD_IO / _IO_VEC, and AFAICT a
>    write-capable confined task can reach IO passthrough (write, DSM/discard) with no
>    capability, since nvme_cmd_allowed() only wants FMODE_WRITE there.
> 
>    Correction to my own report: I overstated the ceiling. The NVMe admin ops
>    (format, sanitize, firmware, security-send) sit behind capable(CAP_SYS_ADMIN)
>    in nvme_cmd_allowed(), so a Landlocked unprivileged task can't reach them. The
>    A:H / 8.4 figure was wrong; only namespace IO is in scope for a confined task.
> 
> 2. Truncate: correct, no sidestep, and none looks possible. I went through every
>    f_op->uring_cmd provider (block, NVMe, btrfs encoded I/O, FUSE, ublk, sockets, ...)
>    and none change file size; truncate(2)/ftruncate(2) keep their own hook. Please
>    ignore the "and truncate where relevant" line in my suggested direction, it was
>    speculative.
> 
> On framing: I'm happy to call this a coverage gap rather than a bypass. IOCTL_DEV was
> never documented to cover io_uring, so nothing it promised is broken. The one hard fact
> is the asymmetry: ioctl(2) BLKDISCARD is denied (IOCTL_DEV, and it's not in
> is_masked_device_ioctl()), the same op via uring_cmd isn't, and SELinux/Smack already
> hook security_uring_cmd while Landlock doesn't. Whether that's worth a hook or just the
> doc clarification Mickaël mentioned is your call.

Agreed, a coverage gap is in my mind the right way to think about it.

I filed this issue about that gap:
https://github.com/landlock-lsm/linux/issues/65

Even though that's technically a feature request, you are quite
right pointing it out.

As I'm saying on that issue description as well, there are in principle
multiple ways of blocking such a feature.  It is possible to block it at
the fine-grained layer in uring_cmd, but maybe a more practical way to
go about it would be to block the creation of an io_uring itself, since
most sandboxed processes do not normally make use of that feature.

(IMHO, we have already made a similar mistake in networking, where we
first built restrictions for individual TCP operations, but left all the
other protocols unrestricted.  Maybe the better approach is to start
with the coarser restriction that addresses the majority of use cases
and then provide more granular controls later.)

I'd be interested to hear people's opinions.

(Mickaël, if you feel this is the wrong approach to frame this as
feature request, also please speak up.)


> If you do want one, I can send an RFC for an all-or-nothing "IOCTL_DEV for any uring_cmd
> on a device file" hook (cmd_op is a private number space, so porting
> is_masked_device_ioctl() wouldn't be right). Otherwise I'll drop the provider detail
> into #64 and leave it at the doc fix.

I'd be happy to review your patches for the issue.  But let's find a
consensus on the overall approach first -- that will hopefully also save
you from going to much in circles in the implementation.

Thanks!
—Günther