[RFC 2/4] landlock: Add LANDLOCK_ACCESS_FS_IOCTL access right
Günther Noack
gnoack at google.com
Fri Jul 14 12:46:09 UTC 2023
Hi!
On Mon, Jun 19, 2023 at 04:42:07PM +0200, Mickaël Salaün wrote:
> I'd like a new documentation paragraph explaining the limitation of
> LANDLOCK_ACCESS_FS_IOCTL (not fine-grained; should be careful about
> fscrypt-like features for regular files; compatibility with TTY and other
> common IOCTLs), a way to get more guarantees (e.g. using nodev mount points
> when possible), and a sentence explaining that future work will enable a
> more fine-grained access control.
I tried to add this comment but realized that I don't understand it well enough -
Regarding fscrypt:
If a process is not the fscrypt user space tool itself, in which ways do the
fscrypt ioctls matter for that process?
I dug up a list of ioctls in tools/include/uapi/linux/fscrypt.h which look
related, but these look like they are only needed for the set up of encrypted
files and directories, but not for using these files later from other
processes?
Am I misunderstanding that?
The one thing that seems to stand out with the fscrypt ioctls is that the same
ioctl numbers are implemented by multiple different file systems.
Regarding nodev mount points:
I guess this is not relevant any more if we split the IOCTL right into a
device-only and non-device-only flag?
(I prefer that solution over nodev mounts as well, because that solution works
unprivileged from the perspective of the process that defines the Landlock
policy. Re-mounting with different options requires more rights and can often
not be influenced by small utilities.)
Thanks,
—Günther
--
Sent using Mutt 🐕 Woof Woof
More information about the Linux-security-module-archive
mailing list