]>
Commit | Line | Data |
---|---|---|
5526b450 MS |
1 | .. SPDX-License-Identifier: GPL-2.0 |
2 | .. Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net> | |
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 | ||
d3122273 MCC |
28 | User space documentation can be found here: |
29 | Documentation/userspace-api/landlock.rst. | |
5526b450 MS |
30 | |
31 | Guiding principles for safe access controls | |
32 | =========================================== | |
33 | ||
34 | * A Landlock rule shall be focused on access control on kernel objects instead | |
35 | of syscall filtering (i.e. syscall arguments), which is the purpose of | |
36 | seccomp-bpf. | |
37 | * To avoid multiple kinds of side-channel attacks (e.g. leak of security | |
38 | policies, CPU-based attacks), Landlock rules shall not be able to | |
39 | programmatically communicate with user space. | |
40 | * Kernel access check shall not slow down access request from unsandboxed | |
41 | processes. | |
42 | * Computation related to Landlock operations (e.g. enforcing a ruleset) shall | |
43 | only impact the processes requesting them. | |
44 | ||
45 | Tests | |
46 | ===== | |
47 | ||
48 | Userspace tests for backward compatibility, ptrace restrictions and filesystem | |
49 | support can be found here: `tools/testing/selftests/landlock/`_. | |
50 | ||
51 | Kernel structures | |
52 | ================= | |
53 | ||
54 | Object | |
55 | ------ | |
56 | ||
57 | .. kernel-doc:: security/landlock/object.h | |
58 | :identifiers: | |
59 | ||
60 | Filesystem | |
61 | ---------- | |
62 | ||
63 | .. kernel-doc:: security/landlock/fs.h | |
64 | :identifiers: | |
65 | ||
66 | Ruleset and domain | |
67 | ------------------ | |
68 | ||
69 | A domain is a read-only ruleset tied to a set of subjects (i.e. tasks' | |
70 | credentials). Each time a ruleset is enforced on a task, the current domain is | |
71 | duplicated and the ruleset is imported as a new layer of rules in the new | |
72 | domain. Indeed, once in a domain, each rule is tied to a layer level. To | |
73 | grant access to an object, at least one rule of each layer must allow the | |
74 | requested action on the object. A task can then only transit to a new domain | |
75 | that is the intersection of the constraints from the current domain and those | |
76 | of a ruleset provided by the task. | |
77 | ||
78 | The definition of a subject is implicit for a task sandboxing itself, which | |
79 | makes the reasoning much easier and helps avoid pitfalls. | |
80 | ||
81 | .. kernel-doc:: security/landlock/ruleset.h | |
82 | :identifiers: | |
83 | ||
84 | .. Links | |
85 | .. _tools/testing/selftests/landlock/: | |
86 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/ |