summaryrefslogtreecommitdiff
path: root/Documentation/security
diff options
context:
space:
mode:
authorMickaël Salaün <mic@digikod.net>2022-12-09 22:38:13 +0300
committerMickaël Salaün <mic@digikod.net>2023-01-13 22:40:35 +0300
commit3e52e5b077f6c3e26801d87335aac35411744108 (patch)
tree3989d20a25897edb392b7cb60717ae6b56d9e730 /Documentation/security
parentb7bfaa761d760e72a969d116517eaa12e404c262 (diff)
downloadlinux-3e52e5b077f6c3e26801d87335aac35411744108.tar.xz
landlock: Explain file descriptor access rights
Starting with LANDLOCK_ACCESS_FS_TRUNCATE, it is worth explaining why we choose to restrict access checks at open time. This new "File descriptor access rights" section is complementary to the existing "Inode access rights" section. Add a new guiding principle related to this section. Reviewed-by: Günther Noack <gnoack3000@gmail.com> Link: https://lore.kernel.org/r/20221209193813.972012-1-mic@digikod.net [mic: Include the latest Günther's suggestion, and fix spelling] Signed-off-by: Mickaël Salaün <mic@digikod.net>
Diffstat (limited to 'Documentation/security')
-rw-r--r--Documentation/security/landlock.rst34
1 files changed, 31 insertions, 3 deletions
diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst
index c0029d5d02eb..36f26501fd15 100644
--- a/Documentation/security/landlock.rst
+++ b/Documentation/security/landlock.rst
@@ -7,7 +7,7 @@ Landlock LSM: kernel documentation
==================================
:Author: Mickaël Salaün
-:Date: September 2022
+:Date: December 2022
Landlock's goal is to create scoped access-control (i.e. sandboxing). To
harden a whole system, this feature should be available to any process,
@@ -41,12 +41,16 @@ Guiding principles for safe access controls
processes.
* Computation related to Landlock operations (e.g. enforcing a ruleset) shall
only impact the processes requesting them.
+* Resources (e.g. file descriptors) directly obtained from the kernel by a
+ sandboxed process shall retain their scoped accesses (at the time of resource
+ acquisition) whatever process use them.
+ Cf. `File descriptor access rights`_.
Design choices
==============
-Filesystem access rights
-------------------------
+Inode access rights
+-------------------
All access rights are tied to an inode and what can be accessed through it.
Reading the content of a directory does not imply to be allowed to read the
@@ -57,6 +61,30 @@ directory, not the unlinked inode. This is the reason why
``LANDLOCK_ACCESS_FS_REMOVE_FILE`` or ``LANDLOCK_ACCESS_FS_REFER`` are not
allowed to be tied to files but only to directories.
+File descriptor access rights
+-----------------------------
+
+Access rights are checked and tied to file descriptors at open time. The
+underlying principle is that equivalent sequences of operations should lead to
+the same results, when they are executed under the same Landlock domain.
+
+Taking the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right as an example, it may be
+allowed to open a file for writing without being allowed to
+:manpage:`ftruncate` the resulting file descriptor if the related file
+hierarchy doesn't grant such access right. The following sequences of
+operations have the same semantic and should then have the same result:
+
+* ``truncate(path);``
+* ``int fd = open(path, O_WRONLY); ftruncate(fd); close(fd);``
+
+Similarly to file access modes (e.g. ``O_RDWR``), Landlock access rights
+attached to file descriptors are retained even if they are passed between
+processes (e.g. through a Unix domain socket). Such access rights will then be
+enforced even if the receiving process is not sandboxed by Landlock. Indeed,
+this is required to keep a consistent access control over the whole system, and
+this avoids unattended bypasses through file descriptor passing (i.e. confused
+deputy attack).
+
Tests
=====