|
| 1 | +.. SPDX-License-Identifier: GPL-2.0 |
| 2 | +.. Copyright © 2017-2020 Mickaël Salaün <[email protected]> |
| 3 | +.. Copyright © 2019-2020 ANSSI |
| 4 | +
|
| 5 | +================================== |
| 6 | +Landlock LSM: kernel documentation |
| 7 | +================================== |
| 8 | + |
| 9 | +:Author: Mickaël Salaün |
| 10 | +:Date: March 2021 |
| 11 | + |
| 12 | +Landlock's goal is to create scoped access-control (i.e. sandboxing). To |
| 13 | +harden a whole system, this feature should be available to any process, |
| 14 | +including unprivileged ones. Because such process may be compromised or |
| 15 | +backdoored (i.e. untrusted), Landlock's features must be safe to use from the |
| 16 | +kernel and other processes point of view. Landlock's interface must therefore |
| 17 | +expose a minimal attack surface. |
| 18 | + |
| 19 | +Landlock is designed to be usable by unprivileged processes while following the |
| 20 | +system security policy enforced by other access control mechanisms (e.g. DAC, |
| 21 | +LSM). Indeed, a Landlock rule shall not interfere with other access-controls |
| 22 | +enforced on the system, only add more restrictions. |
| 23 | + |
| 24 | +Any user can enforce Landlock rulesets on their processes. They are merged and |
| 25 | +evaluated according to the inherited ones in a way that ensures that only more |
| 26 | +constraints can be added. |
| 27 | + |
| 28 | +User space documentation can be found here: :doc:`/userspace-api/landlock`. |
| 29 | + |
| 30 | +Guiding principles for safe access controls |
| 31 | +=========================================== |
| 32 | + |
| 33 | +* A Landlock rule shall be focused on access control on kernel objects instead |
| 34 | + of syscall filtering (i.e. syscall arguments), which is the purpose of |
| 35 | + seccomp-bpf. |
| 36 | +* To avoid multiple kinds of side-channel attacks (e.g. leak of security |
| 37 | + policies, CPU-based attacks), Landlock rules shall not be able to |
| 38 | + programmatically communicate with user space. |
| 39 | +* Kernel access check shall not slow down access request from unsandboxed |
| 40 | + processes. |
| 41 | +* Computation related to Landlock operations (e.g. enforcing a ruleset) shall |
| 42 | + only impact the processes requesting them. |
| 43 | + |
| 44 | +Tests |
| 45 | +===== |
| 46 | + |
| 47 | +Userspace tests for backward compatibility, ptrace restrictions and filesystem |
| 48 | +support can be found here: `tools/testing/selftests/landlock/`_. |
| 49 | + |
| 50 | +Kernel structures |
| 51 | +================= |
| 52 | + |
| 53 | +Object |
| 54 | +------ |
| 55 | + |
| 56 | +.. kernel-doc:: security/landlock/object.h |
| 57 | + :identifiers: |
| 58 | + |
| 59 | +Filesystem |
| 60 | +---------- |
| 61 | + |
| 62 | +.. kernel-doc:: security/landlock/fs.h |
| 63 | + :identifiers: |
| 64 | + |
| 65 | +Ruleset and domain |
| 66 | +------------------ |
| 67 | + |
| 68 | +A domain is a read-only ruleset tied to a set of subjects (i.e. tasks' |
| 69 | +credentials). Each time a ruleset is enforced on a task, the current domain is |
| 70 | +duplicated and the ruleset is imported as a new layer of rules in the new |
| 71 | +domain. Indeed, once in a domain, each rule is tied to a layer level. To |
| 72 | +grant access to an object, at least one rule of each layer must allow the |
| 73 | +requested action on the object. A task can then only transit to a new domain |
| 74 | +that is the intersection of the constraints from the current domain and those |
| 75 | +of a ruleset provided by the task. |
| 76 | + |
| 77 | +The definition of a subject is implicit for a task sandboxing itself, which |
| 78 | +makes the reasoning much easier and helps avoid pitfalls. |
| 79 | + |
| 80 | +.. kernel-doc:: security/landlock/ruleset.h |
| 81 | + :identifiers: |
| 82 | + |
| 83 | +.. Links |
| 84 | +.. _tools/testing/selftests/landlock/: |
| 85 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/ |
0 commit comments