Re: [RFC 2/4] landlock: Add LANDLOCK_ACCESS_FS_IOCTL access right

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

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