[PATCH v3 5/5] landlock: Document ioctl support
Günther Noack
gnoack at google.com
Fri Aug 25 11:55:24 UTC 2023
Hi!
On Fri, Aug 18, 2023 at 06:28:41PM +0200, Mickaël Salaün wrote:
> This looks good!
>
> On Mon, Aug 14, 2023 at 07:28:16PM +0200, Günther Noack wrote:
> > +IOCTL support
> > +-------------
> > +
> > +The ``LANDLOCK_ACCESS_FS_IOCTL`` access right restricts the use of
> > +:manpage:`ioctl(2)`, but it only applies to newly opened files. This means
> > +specifically that pre-existing file descriptors like STDIN, STDOUT and STDERR
>
> According to man pages (and unlike IOCTL commands) we should not
> capitalize stdin, stdout and stderr.
Done.
> > +are unaffected.
> > +
> > +Users should be aware that TTY devices have traditionally permitted to control
> > +other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL
> > +commands. It is therefore recommended to close inherited TTY file descriptors.
>
> Good to see such warnings in the documentation.
>
> We could also propose a simple solution to still uses stdin, stdout and
> stderr without complex TTY proxying: re-opening the TTY, or replacing
> related FD thanks to /proc/self/fd/*
>
> For instance, with shell scripts it would look like this:
> exec </proc/self/fd/0
> exec >/proc/self/fd/1
> exec 2>/proc/self/fd/2
>
> Because of TIOCGWINSZ and TCGETS, an interactive shell may not work as
> expected though.
I inserted the phrase
..., or to reopen them from ``/proc/self/fd/*`` without the
``LANDLOCK_ACCESS_FS_IOCTL`` right, if possible.
to hint at that approach.
I added "if possible" there, because there are thorny edge cases that make it
difficult as a general approach -- the open(2) can fail if a stacked Landlock
policy exists.
—Günther
--
Sent using Mutt 🐕 Woof Woof
More information about the Linux-security-module-archive
mailing list