130 lines · plain
1.. SPDX-License-Identifier: GPL-2.02.. Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net>3.. Copyright © 2019-2020 ANSSI4 5==================================6Landlock LSM: kernel documentation7==================================8 9:Author: Mickaël Salaün10:Date: December 202211 12Landlock's goal is to create scoped access-control (i.e. sandboxing). To13harden a whole system, this feature should be available to any process,14including unprivileged ones. Because such a process may be compromised or15backdoored (i.e. untrusted), Landlock's features must be safe to use from the16kernel and other processes point of view. Landlock's interface must therefore17expose a minimal attack surface.18 19Landlock is designed to be usable by unprivileged processes while following the20system security policy enforced by other access control mechanisms (e.g. DAC,21LSM). A Landlock rule shall not interfere with other access-controls enforced22on the system, only add more restrictions.23 24Any user can enforce Landlock rulesets on their processes. They are merged and25evaluated against inherited rulesets in a way that ensures that only more26constraints can be added.27 28User space documentation can be found here:29Documentation/userspace-api/landlock.rst.30 31Guiding principles for safe access controls32===========================================33 34* A Landlock rule shall be focused on access control on kernel objects instead35 of syscall filtering (i.e. syscall arguments), which is the purpose of36 seccomp-bpf.37* To avoid multiple kinds of side-channel attacks (e.g. leak of security38 policies, CPU-based attacks), Landlock rules shall not be able to39 programmatically communicate with user space.40* Kernel access check shall not slow down access request from unsandboxed41 processes.42* Computation related to Landlock operations (e.g. enforcing a ruleset) shall43 only impact the processes requesting them.44* Resources (e.g. file descriptors) directly obtained from the kernel by a45 sandboxed process shall retain their scoped accesses (at the time of resource46 acquisition) whatever process uses them.47 Cf. `File descriptor access rights`_.48 49Design choices50==============51 52Inode access rights53-------------------54 55All access rights are tied to an inode and what can be accessed through it.56Reading the content of a directory does not imply to be allowed to read the57content of a listed inode. Indeed, a file name is local to its parent58directory, and an inode can be referenced by multiple file names thanks to59(hard) links. Being able to unlink a file only has a direct impact on the60directory, not the unlinked inode. This is the reason why61``LANDLOCK_ACCESS_FS_REMOVE_FILE`` or ``LANDLOCK_ACCESS_FS_REFER`` are not62allowed to be tied to files but only to directories.63 64File descriptor access rights65-----------------------------66 67Access rights are checked and tied to file descriptors at open time. The68underlying principle is that equivalent sequences of operations should lead to69the same results, when they are executed under the same Landlock domain.70 71Taking the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right as an example, it may be72allowed to open a file for writing without being allowed to73:manpage:`ftruncate` the resulting file descriptor if the related file74hierarchy doesn't grant that access right. The following sequences of75operations have the same semantic and should then have the same result:76 77* ``truncate(path);``78* ``int fd = open(path, O_WRONLY); ftruncate(fd); close(fd);``79 80Similarly to file access modes (e.g. ``O_RDWR``), Landlock access rights81attached to file descriptors are retained even if they are passed between82processes (e.g. through a Unix domain socket). Such access rights will then be83enforced even if the receiving process is not sandboxed by Landlock. Indeed,84this is required to keep access controls consistent over the whole system, and85this avoids unattended bypasses through file descriptor passing (i.e. confused86deputy attack).87 88Tests89=====90 91Userspace tests for backward compatibility, ptrace restrictions and filesystem92support can be found here: `tools/testing/selftests/landlock/`_.93 94Kernel structures95=================96 97Object98------99 100.. kernel-doc:: security/landlock/object.h101 :identifiers:102 103Filesystem104----------105 106.. kernel-doc:: security/landlock/fs.h107 :identifiers:108 109Ruleset and domain110------------------111 112A domain is a read-only ruleset tied to a set of subjects (i.e. tasks'113credentials). Each time a ruleset is enforced on a task, the current domain is114duplicated and the ruleset is imported as a new layer of rules in the new115domain. Indeed, once in a domain, each rule is tied to a layer level. To116grant access to an object, at least one rule of each layer must allow the117requested action on the object. A task can then only transit to a new domain118that is the intersection of the constraints from the current domain and those119of a ruleset provided by the task.120 121The definition of a subject is implicit for a task sandboxing itself, which122makes the reasoning much easier and helps avoid pitfalls.123 124.. kernel-doc:: security/landlock/ruleset.h125 :identifiers:126 127.. Links128.. _tools/testing/selftests/landlock/:129 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/130