diff options
Diffstat (limited to 'Documentation/security/landlock.rst')
| -rw-r--r-- | Documentation/security/landlock.rst | 62 |
1 files changed, 55 insertions, 7 deletions
diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst index c0029d5d02eb..3e4d4d04cfae 100644 --- a/Documentation/security/landlock.rst +++ b/Documentation/security/landlock.rst @@ -7,22 +7,22 @@ Landlock LSM: kernel documentation ================================== :Author: Mickaël Salaün -:Date: September 2022 +:Date: September 2025 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, -including unprivileged ones. Because such process may be compromised or +including unprivileged ones. Because such a process may be compromised or backdoored (i.e. untrusted), Landlock's features must be safe to use from the kernel and other processes point of view. Landlock's interface must therefore expose a minimal attack surface. Landlock is designed to be usable by unprivileged processes while following the system security policy enforced by other access control mechanisms (e.g. DAC, -LSM). Indeed, a Landlock rule shall not interfere with other access-controls -enforced on the system, only add more restrictions. +LSM). A Landlock rule shall not interfere with other access-controls enforced +on the system, only add more restrictions. Any user can enforce Landlock rulesets on their processes. They are merged and -evaluated according to the inherited ones in a way that ensures that only more +evaluated against inherited rulesets in a way that ensures that only more constraints can be added. User space documentation can be found here: @@ -41,12 +41,20 @@ 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 uses them. + Cf. `File descriptor access rights`_. +* Access denials shall be logged according to system and Landlock domain + configurations. Log entries must contain information about the cause of the + denial and the owner of the related security policy. Such log generation + should have a negligible performance and memory impact on allowed requests. 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 +65,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 that 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 access controls consistent over the whole system, and +this avoids unattended bypasses through file descriptor passing (i.e. confused +deputy attack). + Tests ===== @@ -78,6 +110,12 @@ Filesystem .. kernel-doc:: security/landlock/fs.h :identifiers: +Process credential +------------------ + +.. kernel-doc:: security/landlock/cred.h + :identifiers: + Ruleset and domain ------------------ @@ -96,6 +134,16 @@ makes the reasoning much easier and helps avoid pitfalls. .. kernel-doc:: security/landlock/ruleset.h :identifiers: +.. kernel-doc:: security/landlock/domain.h + :identifiers: + +Additional documentation +======================== + +* Documentation/userspace-api/landlock.rst +* Documentation/admin-guide/LSM/landlock.rst +* https://landlock.io + .. Links .. _tools/testing/selftests/landlock/: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/ |