On Fri, Dec 1, 2023 at 6:41 AM Günther Noack <gnoack@xxxxxxxxxx> wrote: > > In the paragraph above the fallback logic, use the shorter phrasing > from the landlock(7) man page. > > Signed-off-by: Günther Noack <gnoack@xxxxxxxxxx> > --- > Documentation/userspace-api/landlock.rst | 74 +++++++++++++++++++----- > 1 file changed, 59 insertions(+), 15 deletions(-) > > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst > index 2e3822677061..68498ca64dc9 100644 > --- a/Documentation/userspace-api/landlock.rst > +++ b/Documentation/userspace-api/landlock.rst > @@ -75,7 +75,8 @@ to be explicit about the denied-by-default access rights. > LANDLOCK_ACCESS_FS_MAKE_BLOCK | > LANDLOCK_ACCESS_FS_MAKE_SYM | > LANDLOCK_ACCESS_FS_REFER | > - LANDLOCK_ACCESS_FS_TRUNCATE, > + LANDLOCK_ACCESS_FS_TRUNCATE | > + LANDLOCK_ACCESS_FS_IOCTL, > .handled_access_net = > LANDLOCK_ACCESS_NET_BIND_TCP | > LANDLOCK_ACCESS_NET_CONNECT_TCP, > @@ -84,10 +85,10 @@ to be explicit about the denied-by-default access rights. > Because we may not know on which kernel version an application will be > executed, it is safer to follow a best-effort security approach. Indeed, we > should try to protect users as much as possible whatever the kernel they are > -using. To avoid binary enforcement (i.e. either all security features or > -none), we can leverage a dedicated Landlock command to get the current version > -of the Landlock ABI and adapt the handled accesses. Let's check if we should > -remove access rights which are only supported in higher versions of the ABI. > +using. > + > +To be compatible with older Linux versions, we detect the available Landlock ABI > +version, and only use the available subset of access rights: > > .. code-block:: c > > @@ -113,6 +114,10 @@ remove access rights which are only supported in higher versions of the ABI. > ruleset_attr.handled_access_net &= > ~(LANDLOCK_ACCESS_NET_BIND_TCP | > LANDLOCK_ACCESS_NET_CONNECT_TCP); > + __attribute__((fallthrough)); > + case 4: > + /* Removes LANDLOCK_ACCESS_FS_IOCTL for ABI < 5 */ > + ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_IOCTL; > } > > This enables to create an inclusive ruleset that will contain our rules. > @@ -224,6 +229,7 @@ access rights per directory enables to change the location of such directory > without relying on the destination directory access rights (except those that > are required for this operation, see ``LANDLOCK_ACCESS_FS_REFER`` > documentation). > + > Having self-sufficient hierarchies also helps to tighten the required access > rights to the minimal set of data. This also helps avoid sinkhole directories, > i.e. directories where data can be linked to but not linked from. However, > @@ -317,18 +323,24 @@ It should also be noted that truncating files does not require the > system call, this can also be done through :manpage:`open(2)` with the flags > ``O_RDONLY | O_TRUNC``. > > -When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` > -right is associated with the newly created file descriptor and will be used for > -subsequent truncation attempts using :manpage:`ftruncate(2)`. The behavior is > -similar to opening a file for reading or writing, where permissions are checked > -during :manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and > +The truncate right is associated with the opened file (see below). > + > +Rights associated with file descriptors > +--------------------------------------- > + > +When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` and > +``LANDLOCK_ACCESS_FS_IOCTL`` rights is associated with the newly created file > +descriptor and will be used for subsequent truncation and ioctl attempts using > +:manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar to > +opening a file for reading or writing, where permissions are checked during > +:manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and > :manpage:`write(2)` calls. > > -As a consequence, it is possible to have multiple open file descriptors for the > -same file, where one grants the right to truncate the file and the other does > -not. It is also possible to pass such file descriptors between processes, > -keeping their Landlock properties, even when these processes do not have an > -enforced Landlock ruleset. > +As a consequence, it is possible to have multiple open file descriptors > +referring to the same file, where one grants the truncate or ioctl right and the > +other does not. It is also possible to pass such file descriptors between > +processes, keeping their Landlock properties, even when these processes do not > +have an enforced Landlock ruleset. > I understand the "passing fd between process ", but not the " multiple open fds referring to the same file, with different permission", are those fds all opened within the same domain ? Can we have a pseudocode to help understanding ? -Jeff
