Landlock Ioctl Control
✅ since Linux 6.10 | 💾 Patch Set v15 | 🐞 Github issue #4
This feature is available since Linux 6.10.
Short summary
This patch set introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right, which restricts the
use of ioctl(2) on block and character devices.
This access right applies to all ioctl(2) commands implemented by device
drivers. However, the following common IOCTL commands continue to be
invokable on device files independent of the LANDLOCK_ACCESS_FS_IOCTL_DEV right:
- IOCTL commands targeting file descriptors (
FIOCLEX,FIONCLEX), - IOCTL commands targeting file descriptions (
FIONBIO,FIOASYNC), - IOCTL commands targeting file systems (
FIFREEZE,FITHAW,FIGETBSZ,FS_IOC_GETFSUUID,FS_IOC_GETFSSYSFSPATH) - Some IOCTL commands which do not make sense when used with devices, but
whose implementations are safe and return the right error codes
(
FS_IOC_FIEMAP,FICLONE,FICLONERANGE,FIDEDUPERANGE)
When determining whether a specific IOCTL command should be permitted, is is the Landlock policy at the time of opening the file from the file system which determines the outcome.
The same approach is already used for LANDLOCK_ACCESS_FS_TRUNCATE.
💡 This means that IOCTL is probably possible if a process inherits TTY file descriptors or other files from the parent process, even when the child process restricts the use of IOCTL with a Landlock policy later (TerminalFileDescriptorProblem).
💡 The inverse is also true: If a process opens a device file in a way so that IOCTL is restricted under a Landlock policy, this process can use UnixDomainSockets to pass the file descriptor to another process. The file descriptor carries its IOCTL policy with it, and the same policies will be enforced in that process as well, independent of whether the receiving process is aware of Landlock or not.