1Landlock(7) Miscellaneous Information Manual Landlock(7)
2
3
4
6 Landlock - unprivileged access-control
7
9 Landlock is an access-control system that enables any processes to se‐
10 curely restrict themselves and their future children. Because Landlock
11 is a stackable Linux Security Module (LSM), it makes it possible to
12 create safe security sandboxes as new security layers in addition to
13 the existing system-wide access-controls. This kind of sandbox is ex‐
14 pected to help mitigate the security impact of bugs, and unexpected or
15 malicious behaviors in applications.
16
17 A Landlock security policy is a set of access rights (e.g., open a file
18 in read-only, make a directory, etc.) tied to a file hierarchy. Such
19 policy can be configured and enforced by processes for themselves using
20 three system calls:
21
22 • landlock_create_ruleset(2) creates a new ruleset;
23
24 • landlock_add_rule(2) adds a new rule to a ruleset;
25
26 • landlock_restrict_self(2) enforces a ruleset on the calling thread.
27
28 To be able to use these system calls, the running kernel must support
29 Landlock and it must be enabled at boot time.
30
31 Landlock rules
32 A Landlock rule describes an action on an object. An object is cur‐
33 rently a file hierarchy, and the related filesystem actions are defined
34 with access rights (see landlock_add_rule(2)). A set of rules is ag‐
35 gregated in a ruleset, which can then restrict the thread enforcing it,
36 and its future children.
37
38 Filesystem actions
39 These flags enable to restrict a sandboxed process to a set of actions
40 on files and directories. Files or directories opened before the sand‐
41 boxing are not subject to these restrictions. See landlock_add_rule(2)
42 and landlock_create_ruleset(2) for more context.
43
44 A file can only receive these access rights:
45
46 LANDLOCK_ACCESS_FS_EXECUTE
47 Execute a file.
48
49 LANDLOCK_ACCESS_FS_WRITE_FILE
50 Open a file with write access.
51
52 When opening files for writing, you will often additionally need
53 the LANDLOCK_ACCESS_FS_TRUNCATE right. In many cases, these
54 system calls truncate existing files when overwriting them
55 (e.g., creat(2)).
56
57 LANDLOCK_ACCESS_FS_READ_FILE
58 Open a file with read access.
59
60 LANDLOCK_ACCESS_FS_TRUNCATE
61 Truncate a file with truncate(2), ftruncate(2), creat(2), or
62 open(2) with O_TRUNC. Whether an opened file can be truncated
63 with ftruncate(2) is determined during open(2), in the same way
64 as read and write permissions are checked during open(2) using
65 LANDLOCK_ACCESS_FS_READ_FILE and LANDLOCK_ACCESS_FS_WRITE_FILE.
66 This access right is available since the third version of the
67 Landlock ABI.
68
69 A directory can receive access rights related to files or directories.
70 The following access right is applied to the directory itself, and the
71 directories beneath it:
72
73 LANDLOCK_ACCESS_FS_READ_DIR
74 Open a directory or list its content.
75
76 However, the following access rights only apply to the content of a di‐
77 rectory, not the directory itself:
78
79 LANDLOCK_ACCESS_FS_REMOVE_DIR
80 Remove an empty directory or rename one.
81
82 LANDLOCK_ACCESS_FS_REMOVE_FILE
83 Unlink (or rename) a file.
84
85 LANDLOCK_ACCESS_FS_MAKE_CHAR
86 Create (or rename or link) a character device.
87
88 LANDLOCK_ACCESS_FS_MAKE_DIR
89 Create (or rename) a directory.
90
91 LANDLOCK_ACCESS_FS_MAKE_REG
92 Create (or rename or link) a regular file.
93
94 LANDLOCK_ACCESS_FS_MAKE_SOCK
95 Create (or rename or link) a UNIX domain socket.
96
97 LANDLOCK_ACCESS_FS_MAKE_FIFO
98 Create (or rename or link) a named pipe.
99
100 LANDLOCK_ACCESS_FS_MAKE_BLOCK
101 Create (or rename or link) a block device.
102
103 LANDLOCK_ACCESS_FS_MAKE_SYM
104 Create (or rename or link) a symbolic link.
105
106 LANDLOCK_ACCESS_FS_REFER
107 Link or rename a file from or to a different directory (i.e.,
108 reparent a file hierarchy).
109
110 This access right is available since the second version of the
111 Landlock ABI.
112
113 This is the only access right which is denied by default by any
114 ruleset, even if the right is not specified as handled at rule‐
115 set creation time. The only way to make a ruleset grant this
116 right is to explicitly allow it for a specific directory by
117 adding a matching rule to the ruleset.
118
119 In particular, when using the first Landlock ABI version, Land‐
120 lock will always deny attempts to reparent files between differ‐
121 ent directories.
122
123 In addition to the source and destination directories having the
124 LANDLOCK_ACCESS_FS_REFER access right, the attempted link or re‐
125 name operation must meet the following constraints:
126
127 • The reparented file may not gain more access rights in the
128 destination directory than it previously had in the source
129 directory. If this is attempted, the operation results in an
130 EXDEV error.
131
132 • When linking or renaming, the LANDLOCK_ACCESS_FS_MAKE_* right
133 for the respective file type must be granted for the destina‐
134 tion directory. Otherwise, the operation results in an EAC‐
135 CES error.
136
137 • When renaming, the LANDLOCK_ACCESS_FS_REMOVE_* right for the
138 respective file type must be granted for the source direc‐
139 tory. Otherwise, the operation results in an EACCES error.
140
141 If multiple requirements are not met, the EACCES error code
142 takes precedence over EXDEV.
143
144 Layers of file path access rights
145 Each time a thread enforces a ruleset on itself, it updates its Land‐
146 lock domain with a new layer of policy. Indeed, this complementary
147 policy is composed with the potentially other rulesets already re‐
148 stricting this thread. A sandboxed thread can then safely add more
149 constraints to itself with a new enforced ruleset.
150
151 One policy layer grants access to a file path if at least one of its
152 rules encountered on the path grants the access. A sandboxed thread
153 can only access a file path if all its enforced policy layers grant the
154 access as well as all the other system access controls (e.g., filesys‐
155 tem DAC, other LSM policies, etc.).
156
157 Bind mounts and OverlayFS
158 Landlock enables restricting access to file hierarchies, which means
159 that these access rights can be propagated with bind mounts (cf.
160 mount_namespaces(7)) but not with OverlayFS.
161
162 A bind mount mirrors a source file hierarchy to a destination. The
163 destination hierarchy is then composed of the exact same files, on
164 which Landlock rules can be tied, either via the source or the destina‐
165 tion path. These rules restrict access when they are encountered on a
166 path, which means that they can restrict access to multiple file hier‐
167 archies at the same time, whether these hierarchies are the result of
168 bind mounts or not.
169
170 An OverlayFS mount point consists of upper and lower layers. These
171 layers are combined in a merge directory, result of the mount point.
172 This merge hierarchy may include files from the upper and lower layers,
173 but modifications performed on the merge hierarchy only reflect on the
174 upper layer. From a Landlock policy point of view, each of the Over‐
175 layFS layers and merge hierarchies is standalone and contains its own
176 set of files and directories, which is different from a bind mount. A
177 policy restricting an OverlayFS layer will not restrict the resulted
178 merged hierarchy, and vice versa. Landlock users should then only
179 think about file hierarchies they want to allow access to, regardless
180 of the underlying filesystem.
181
182 Inheritance
183 Every new thread resulting from a clone(2) inherits Landlock domain re‐
184 strictions from its parent. This is similar to the seccomp(2) inheri‐
185 tance or any other LSM dealing with tasks' credentials(7). For in‐
186 stance, one process's thread may apply Landlock rules to itself, but
187 they will not be automatically applied to other sibling threads (unlike
188 POSIX thread credential changes, cf. nptl(7)).
189
190 When a thread sandboxes itself, we have the guarantee that the related
191 security policy will stay enforced on all this thread's descendants.
192 This allows creating standalone and modular security policies per ap‐
193 plication, which will automatically be composed between themselves ac‐
194 cording to their runtime parent policies.
195
196 Ptrace restrictions
197 A sandboxed process has less privileges than a non-sandboxed process
198 and must then be subject to additional restrictions when manipulating
199 another process. To be allowed to use ptrace(2) and related syscalls
200 on a target process, a sandboxed process should have a subset of the
201 target process rules, which means the tracee must be in a sub-domain of
202 the tracer.
203
204 Truncating files
205 The operations covered by LANDLOCK_ACCESS_FS_WRITE_FILE and LAND‐
206 LOCK_ACCESS_FS_TRUNCATE both change the contents of a file and some‐
207 times overlap in non-intuitive ways. It is recommended to always spec‐
208 ify both of these together.
209
210 A particularly surprising example is creat(2). The name suggests that
211 this system call requires the rights to create and write files. How‐
212 ever, it also requires the truncate right if an existing file under the
213 same name is already present.
214
215 It should also be noted that truncating files does not require the
216 LANDLOCK_ACCESS_FS_WRITE_FILE right. Apart from the truncate(2) system
217 call, this can also be done through open(2) with the flags
218 O_RDONLY | O_TRUNC.
219
220 When opening a file, the availability of the LANDLOCK_ACCESS_FS_TRUN‐
221 CATE right is associated with the newly created file descriptor and
222 will be used for subsequent truncation attempts using ftruncate(2).
223 The behavior is similar to opening a file for reading or writing, where
224 permissions are checked during open(2), but not during the subsequent
225 read(2) and write(2) calls.
226
227 As a consequence, it is possible to have multiple open file descriptors
228 for the same file, where one grants the right to truncate the file and
229 the other does not. It is also possible to pass such file descriptors
230 between processes, keeping their Landlock properties, even when these
231 processes do not have an enforced Landlock ruleset.
232
234 Landlock was introduced in Linux 5.13.
235
236 To determine which Landlock features are available, users should query
237 the Landlock ABI version:
238
239 ┌────┬────────┬────────────────────────────────────────────────────────┐
240 │ABI │ Kernel │ Newly introduced access rights │
241 ├────┼────────┼────────────────────────────────────────────────────────┤
242 │ 1 │ 5.13 │ LANDLOCK_ACCESS_FS_EXECUTE │
243 │ │ │ LANDLOCK_ACCESS_FS_WRITE_FILE │
244 │ │ │ LANDLOCK_ACCESS_FS_READ_FILE │
245 │ │ │ LANDLOCK_ACCESS_FS_READ_DIR │
246 │ │ │ LANDLOCK_ACCESS_FS_REMOVE_DIR │
247 │ │ │ LANDLOCK_ACCESS_FS_REMOVE_FILE │
248 │ │ │ LANDLOCK_ACCESS_FS_MAKE_CHAR │
249 │ │ │ LANDLOCK_ACCESS_FS_MAKE_DIR │
250 │ │ │ LANDLOCK_ACCESS_FS_MAKE_REG │
251 │ │ │ LANDLOCK_ACCESS_FS_MAKE_SOCK │
252 │ │ │ LANDLOCK_ACCESS_FS_MAKE_FIFO │
253 │ │ │ LANDLOCK_ACCESS_FS_MAKE_BLOCK │
254 │ │ │ LANDLOCK_ACCESS_FS_MAKE_SYM │
255 ├────┼────────┼────────────────────────────────────────────────────────┤
256 │ 2 │ 5.19 │ LANDLOCK_ACCESS_FS_REFER │
257 ├────┼────────┼────────────────────────────────────────────────────────┤
258 │ 3 │ 6.2 │ LANDLOCK_ACCESS_FS_TRUNCATE │
259 └────┴────────┴────────────────────────────────────────────────────────┘
260
261 Users should use the Landlock ABI version rather than the kernel ver‐
262 sion to determine which features are available. The mainline kernel
263 versions listed here are only included for orientation. Kernels from
264 other sources may contain backported features, and their version num‐
265 bers may not match.
266
267 To query the running kernel's Landlock ABI version, programs may pass
268 the LANDLOCK_CREATE_RULESET_VERSION flag to landlock_create_ruleset(2).
269
270 When building fallback mechanisms for compatibility with older kernels,
271 users are advised to consider the special semantics of the LANDLOCK_AC‐
272 CESS_FS_REFER access right: In ABI v1, linking and moving of files be‐
273 tween different directories is always forbidden, so programs relying on
274 such operations are only compatible with Landlock ABI v2 and higher.
275
277 Landlock is enabled by CONFIG_SECURITY_LANDLOCK. The lsm=lsm1,...,lsmN
278 command line parameter controls the sequence of the initialization of
279 Linux Security Modules. It must contain the string landlock to enable
280 Landlock. If the command line parameter is not specified, the initial‐
281 ization falls back to the value of the deprecated security= command
282 line parameter and further to the value of CONFIG_LSM. We can check
283 that Landlock is enabled by looking for landlock: Up and running. in
284 kernel logs.
285
287 It is currently not possible to restrict some file-related actions ac‐
288 cessible through these system call families: chdir(2), stat(2),
289 flock(2), chmod(2), chown(2), setxattr(2), utime(2), ioctl(2), fc‐
290 ntl(2), access(2). Future Landlock evolutions will enable to restrict
291 them.
292
294 We first need to create the ruleset that will contain our rules. For
295 this example, the ruleset will contain rules that only allow read ac‐
296 tions, but write actions will be denied. The ruleset then needs to
297 handle both of these kinds of actions. See below for the description
298 of filesystem actions.
299
300 struct landlock_ruleset_attr attr = {0};
301 int ruleset_fd;
302
303 attr.handled_access_fs =
304 LANDLOCK_ACCESS_FS_EXECUTE |
305 LANDLOCK_ACCESS_FS_WRITE_FILE |
306 LANDLOCK_ACCESS_FS_READ_FILE |
307 LANDLOCK_ACCESS_FS_READ_DIR |
308 LANDLOCK_ACCESS_FS_REMOVE_DIR |
309 LANDLOCK_ACCESS_FS_REMOVE_FILE |
310 LANDLOCK_ACCESS_FS_MAKE_CHAR |
311 LANDLOCK_ACCESS_FS_MAKE_DIR |
312 LANDLOCK_ACCESS_FS_MAKE_REG |
313 LANDLOCK_ACCESS_FS_MAKE_SOCK |
314 LANDLOCK_ACCESS_FS_MAKE_FIFO |
315 LANDLOCK_ACCESS_FS_MAKE_BLOCK |
316 LANDLOCK_ACCESS_FS_MAKE_SYM |
317 LANDLOCK_ACCESS_FS_REFER |
318 LANDLOCK_ACCESS_FS_TRUNCATE;
319
320 ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
321 if (ruleset_fd == -1) {
322 perror("Failed to create a ruleset");
323 exit(EXIT_FAILURE);
324 }
325
326 We can now add a new rule to this ruleset thanks to the returned file
327 descriptor referring to this ruleset. The rule will only allow reading
328 the file hierarchy /usr. Without another rule, write actions would
329 then be denied by the ruleset. To add /usr to the ruleset, we open it
330 with the O_PATH flag and fill the struct landlock_path_beneath_attr
331 with this file descriptor.
332
333 struct landlock_path_beneath_attr path_beneath = {0};
334 int err;
335
336 path_beneath.allowed_access =
337 LANDLOCK_ACCESS_FS_EXECUTE |
338 LANDLOCK_ACCESS_FS_READ_FILE |
339 LANDLOCK_ACCESS_FS_READ_DIR;
340
341 path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
342 if (path_beneath.parent_fd == -1) {
343 perror("Failed to open file");
344 close(ruleset_fd);
345 exit(EXIT_FAILURE);
346 }
347 err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
348 &path_beneath, 0);
349 close(path_beneath.parent_fd);
350 if (err) {
351 perror("Failed to update ruleset");
352 close(ruleset_fd);
353 exit(EXIT_FAILURE);
354 }
355
356 We now have a ruleset with one rule allowing read access to /usr while
357 denying all other handled accesses for the filesystem. The next step
358 is to restrict the current thread from gaining more privileges (e.g.,
359 thanks to a set-user-ID binary).
360
361 if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
362 perror("Failed to restrict privileges");
363 close(ruleset_fd);
364 exit(EXIT_FAILURE);
365 }
366
367 The current thread is now ready to sandbox itself with the ruleset.
368
369 if (landlock_restrict_self(ruleset_fd, 0)) {
370 perror("Failed to enforce ruleset");
371 close(ruleset_fd);
372 exit(EXIT_FAILURE);
373 }
374 close(ruleset_fd);
375
376 If the landlock_restrict_self(2) system call succeeds, the current
377 thread is now restricted and this policy will be enforced on all its
378 subsequently created children as well. Once a thread is landlocked,
379 there is no way to remove its security policy; only adding more re‐
380 strictions is allowed. These threads are now in a new Landlock domain,
381 merge of their parent one (if any) with the new ruleset.
382
383 Full working code can be found in ⟨https://git.kernel.org/pub/scm/
384 linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c⟩
385
387 landlock_create_ruleset(2), landlock_add_rule(2), landlock_re‐
388 strict_self(2)
389
390 ⟨https://landlock.io/⟩
391
392
393
394Linux man-pages 6.04 2023-04-02 Landlock(7)