Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD

[Bryam Vargas <hexlabsecurity@proton.me>]

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.

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.

Bryam