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

[Mickaël Salaün]

On Fri, Jul 14, 2023 at 02:46:09PM +0200, Günther Noack wrote:
> 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?

These IOCTLs may be only used by the fscrypt tool on most distros but
there are of course no guarantee any application could use it to encrypt
its own files according to various use cases.

> 
>   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?

Correct

> 
>   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.

My point was to highlight that nodev IOCTLs might be used by user space
on regular files and directories, not only /dev files, and we should be
careful to not inadvertently deny legitimate IOCTLs.  I think
nodev-IOCTLs are legitimate for unprivileged users, taking into account
capability checks and file mode checks, which might not be the case for
IOCTLs implemented by drivers.

You can take a look ad do_vfs_ioctl() to get a hint about other
FS-related IOCTLs (i.e. FIGETBSZ, FIONREAD), and all other nodev-files
(e.g. pipe, sockets) IOCTLs that may be required to properly use them.

We should be careful to find the good balance between restricting as
much as possible but without breaking user space and bother users that
would then disable security features. ;)

> 
> 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.)

We're now going withouth the split, but this nodev property could in fact
be part of step 2 (or 3).  Indeed, being able to differenciate file type
would enable to enforce a nodev-like control over a file hierarchy.

> 
> Thanks,
> —Günther
> 
> -- 
> Sent using Mutt 🐕 Woof Woof
>