1 .. SPDX-License-Identifier: GPL-2.0
2 .. Copyright © 2017-2020 Mickaël Salaün <mic@digikod.net>
3 .. Copyright © 2019-2020 ANSSI
4 .. Copyright © 2021-2022 Microsoft Corporation
5
6 =====================================
7 Landlock: unprivileged access control
8 =====================================
9
10 :Author: Mickaël Salaün
11 :Date: July 2024
12
13 The goal of Landlock is to enable to restrict ambient rights (e.g. global
14 filesystem or network access) for a set of processes. Because Landlock
15 is a stackable LSM, it makes possible to create safe security sandboxes as new
16 security layers in addition to the existing system-wide access-controls. This
17 kind of sandbox is expected to help mitigate the security impact of bugs or
18 unexpected/malicious behaviors in user space applications. Landlock empowers
19 any process, including unprivileged ones, to securely restrict themselves.
20
21 We can quickly make sure that Landlock is enabled in the running system by
22 looking for "landlock: Up and running" in kernel logs (as root):
23 ``dmesg | grep landlock || journalctl -kb -g landlock`` .
24 Developers can also easily check for Landlock support with a
25 :ref:`related system call <landlock_abi_versions>`.
26 If Landlock is not currently supported, we need to
27 :ref:`configure the kernel appropriately <kernel_support>`.
28
29 Landlock rules
30 ==============
31
32 A Landlock rule describes an action on an object which the process intends to
33 perform. A set of rules is aggregated in a ruleset, which can then restrict
34 the thread enforcing it, and its future children.
35
36 The two existing types of rules are:
37
38 Filesystem rules
39 For these rules, the object is a file hierarchy,
40 and the related filesystem actions are defined with
41 `filesystem access rights`.
42
43 Network rules (since ABI v4)
44 For these rules, the object is a TCP port,
45 and the related actions are defined with `network access rights`.
46
47 Defining and enforcing a security policy
48 ----------------------------------------
49
50 We first need to define the ruleset that will contain our rules.
51
52 For this example, the ruleset will contain rules that only allow filesystem
53 read actions and establish a specific TCP connection. Filesystem write
54 actions and other TCP actions will be denied.
55
56 The ruleset then needs to handle both these kinds of actions. This is
57 required for backward and forward compatibility (i.e. the kernel and user
58 space may not know each other's supported restrictions), hence the need
59 to be explicit about the denied-by-default access rights.
60
61 .. code-block:: c
62
63 struct landlock_ruleset_attr ruleset_attr = {
64 .handled_access_fs =
65 LANDLOCK_ACCESS_FS_EXECUTE |
66 LANDLOCK_ACCESS_FS_WRITE_FILE |
67 LANDLOCK_ACCESS_FS_READ_FILE |
68 LANDLOCK_ACCESS_FS_READ_DIR |
69 LANDLOCK_ACCESS_FS_REMOVE_DIR |
70 LANDLOCK_ACCESS_FS_REMOVE_FILE |
71 LANDLOCK_ACCESS_FS_MAKE_CHAR |
72 LANDLOCK_ACCESS_FS_MAKE_DIR |
73 LANDLOCK_ACCESS_FS_MAKE_REG |
74 LANDLOCK_ACCESS_FS_MAKE_SOCK |
75 LANDLOCK_ACCESS_FS_MAKE_FIFO |
76 LANDLOCK_ACCESS_FS_MAKE_BLOCK |
77 LANDLOCK_ACCESS_FS_MAKE_SYM |
78 LANDLOCK_ACCESS_FS_REFER |
79 LANDLOCK_ACCESS_FS_TRUNCATE |
80 LANDLOCK_ACCESS_FS_IOCTL_DEV,
81 .handled_access_net =
82 LANDLOCK_ACCESS_NET_BIND_TCP |
83 LANDLOCK_ACCESS_NET_CONNECT_TCP,
84 };
85
86 Because we may not know on which kernel version an application will be
87 executed, it is safer to follow a best-effort security approach. Indeed, we
88 should try to protect users as much as possible whatever the kernel they are
89 using.
90
91 To be compatible with older Linux versions, we detect the available Landlock ABI
92 version, and only use the available subset of access rights:
93
94 .. code-block:: c
95
96 int abi;
97
98 abi = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION);
99 if (abi < 0) {
100 /* Degrades gracefully if Landlock is not handled. */
101 perror("The running kernel does not enable to use Landlock");
102 return 0;
103 }
104 switch (abi) {
105 case 1:
106 /* Removes LANDLOCK_ACCESS_FS_REFER for ABI < 2 */
107 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_REFER;
108 __attribute__((fallthrough));
109 case 2:
110 /* Removes LANDLOCK_ACCESS_FS_TRUNCATE for ABI < 3 */
111 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_TRUNCATE;
112 __attribute__((fallthrough));
113 case 3:
114 /* Removes network support for ABI < 4 */
115 ruleset_attr.handled_access_net &=
116 ~(LANDLOCK_ACCESS_NET_BIND_TCP |
117 LANDLOCK_ACCESS_NET_CONNECT_TCP);
118 __attribute__((fallthrough));
119 case 4:
120 /* Removes LANDLOCK_ACCESS_FS_IOCTL_DEV for ABI < 5 */
121 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_IOCTL_DEV;
122 }
123
124 This enables to create an inclusive ruleset that will contain our rules.
125
126 .. code-block:: c
127
128 int ruleset_fd;
129
130 ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
131 if (ruleset_fd < 0) {
132 perror("Failed to create a ruleset");
133 return 1;
134 }
135
136 We can now add a new rule to this ruleset thanks to the returned file
137 descriptor referring to this ruleset. The rule will only allow reading the
138 file hierarchy ``/usr``. Without another rule, write actions would then be
139 denied by the ruleset. To add ``/usr`` to the ruleset, we open it with the
140 ``O_PATH`` flag and fill the &struct landlock_path_beneath_attr with this file
141 descriptor.
142
143 .. code-block:: c
144
145 int err;
146 struct landlock_path_beneath_attr path_beneath = {
147 .allowed_access =
148 LANDLOCK_ACCESS_FS_EXECUTE |
149 LANDLOCK_ACCESS_FS_READ_FILE |
150 LANDLOCK_ACCESS_FS_READ_DIR,
151 };
152
153 path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
154 if (path_beneath.parent_fd < 0) {
155 perror("Failed to open file");
156 close(ruleset_fd);
157 return 1;
158 }
159 err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
160 &path_beneath, 0);
161 close(path_beneath.parent_fd);
162 if (err) {
163 perror("Failed to update ruleset");
164 close(ruleset_fd);
165 return 1;
166 }
167
168 It may also be required to create rules following the same logic as explained
169 for the ruleset creation, by filtering access rights according to the Landlock
170 ABI version. In this example, this is not required because all of the requested
171 ``allowed_access`` rights are already available in ABI 1.
172
173 For network access-control, we can add a set of rules that allow to use a port
174 number for a specific action: HTTPS connections.
175
176 .. code-block:: c
177
178 struct landlock_net_port_attr net_port = {
179 .allowed_access = LANDLOCK_ACCESS_NET_CONNECT_TCP,
180 .port = 443,
181 };
182
183 err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT,
184 &net_port, 0);
185
186 The next step is to restrict the current thread from gaining more privileges
187 (e.g. through a SUID binary). We now have a ruleset with the first rule
188 allowing read access to ``/usr`` while denying all other handled accesses for
189 the filesystem, and a second rule allowing HTTPS connections.
190
191 .. code-block:: c
192
193 if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
194 perror("Failed to restrict privileges");
195 close(ruleset_fd);
196 return 1;
197 }
198
199 The current thread is now ready to sandbox itself with the ruleset.
200
201 .. code-block:: c
202
203 if (landlock_restrict_self(ruleset_fd, 0)) {
204 perror("Failed to enforce ruleset");
205 close(ruleset_fd);
206 return 1;
207 }
208 close(ruleset_fd);
209
210 If the ``landlock_restrict_self`` system call succeeds, the current thread is
211 now restricted and this policy will be enforced on all its subsequently created
212 children as well. Once a thread is landlocked, there is no way to remove its
213 security policy; only adding more restrictions is allowed. These threads are
214 now in a new Landlock domain, merge of their parent one (if any) with the new
215 ruleset.
216
217 Full working code can be found in `samples/landlock/sandboxer.c`_.
218
219 Good practices
220 --------------
221
222 It is recommended setting access rights to file hierarchy leaves as much as
223 possible. For instance, it is better to be able to have ``~/doc/`` as a
224 read-only hierarchy and ``~/tmp/`` as a read-write hierarchy, compared to
225 ``~/`` as a read-only hierarchy and ``~/tmp/`` as a read-write hierarchy.
226 Following this good practice leads to self-sufficient hierarchies that do not
227 depend on their location (i.e. parent directories). This is particularly
228 relevant when we want to allow linking or renaming. Indeed, having consistent
229 access rights per directory enables to change the location of such directory
230 without relying on the destination directory access rights (except those that
231 are required for this operation, see ``LANDLOCK_ACCESS_FS_REFER``
232 documentation).
233
234 Having self-sufficient hierarchies also helps to tighten the required access
235 rights to the minimal set of data. This also helps avoid sinkhole directories,
236 i.e. directories where data can be linked to but not linked from. However,
237 this depends on data organization, which might not be controlled by developers.
238 In this case, granting read-write access to ``~/tmp/``, instead of write-only
239 access, would potentially allow to move ``~/tmp/`` to a non-readable directory
240 and still keep the ability to list the content of ``~/tmp/``.
241
242 Layers of file path access rights
243 ---------------------------------
244
245 Each time a thread enforces a ruleset on itself, it updates its Landlock domain
246 with a new layer of policy. Indeed, this complementary policy is stacked with
247 the potentially other rulesets already restricting this thread. A sandboxed
248 thread can then safely add more constraints to itself with a new enforced
249 ruleset.
250
251 One policy layer grants access to a file path if at least one of its rules
252 encountered on the path grants the access. A sandboxed thread can only access
253 a file path if all its enforced policy layers grant the access as well as all
254 the other system access controls (e.g. filesystem DAC, other LSM policies,
255 etc.).
256
257 Bind mounts and OverlayFS
258 -------------------------
259
260 Landlock enables to restrict access to file hierarchies, which means that these
261 access rights can be propagated with bind mounts (cf.
262 Documentation/filesystems/sharedsubtree.rst) but not with
263 Documentation/filesystems/overlayfs.rst.
264
265 A bind mount mirrors a source file hierarchy to a destination. The destination
266 hierarchy is then composed of the exact same files, on which Landlock rules can
267 be tied, either via the source or the destination path. These rules restrict
268 access when they are encountered on a path, which means that they can restrict
269 access to multiple file hierarchies at the same time, whether these hierarchies
270 are the result of bind mounts or not.
271
272 An OverlayFS mount point consists of upper and lower layers. These layers are
273 combined in a merge directory, result of the mount point. This merge hierarchy
274 may include files from the upper and lower layers, but modifications performed
275 on the merge hierarchy only reflects on the upper layer. From a Landlock
276 policy point of view, each OverlayFS layers and merge hierarchies are
277 standalone and contains their own set of files and directories, which is
278 different from bind mounts. A policy restricting an OverlayFS layer will not
279 restrict the resulted merged hierarchy, and vice versa. Landlock users should
280 then only think about file hierarchies they want to allow access to, regardless
281 of the underlying filesystem.
282
283 Inheritance
284 -----------
285
286 Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain
287 restrictions from its parent. This is similar to the seccomp inheritance (cf.
288 Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with
289 task's :manpage:`credentials(7)`. For instance, one process's thread may apply
290 Landlock rules to itself, but they will not be automatically applied to other
291 sibling threads (unlike POSIX thread credential changes, cf.
292 :manpage:`nptl(7)`).
293
294 When a thread sandboxes itself, we have the guarantee that the related security
295 policy will stay enforced on all this thread's descendants. This allows
296 creating standalone and modular security policies per application, which will
297 automatically be composed between themselves according to their runtime parent
298 policies.
299
300 Ptrace restrictions
301 -------------------
302
303 A sandboxed process has less privileges than a non-sandboxed process and must
304 then be subject to additional restrictions when manipulating another process.
305 To be allowed to use :manpage:`ptrace(2)` and related syscalls on a target
306 process, a sandboxed process should have a subset of the target process rules,
307 which means the tracee must be in a sub-domain of the tracer.
308
309 Truncating files
310 ----------------
311
312 The operations covered by ``LANDLOCK_ACCESS_FS_WRITE_FILE`` and
313 ``LANDLOCK_ACCESS_FS_TRUNCATE`` both change the contents of a file and sometimes
314 overlap in non-intuitive ways. It is recommended to always specify both of
315 these together.
316
317 A particularly surprising example is :manpage:`creat(2)`. The name suggests
318 that this system call requires the rights to create and write files. However,
319 it also requires the truncate right if an existing file under the same name is
320 already present.
321
322 It should also be noted that truncating files does not require the
323 ``LANDLOCK_ACCESS_FS_WRITE_FILE`` right. Apart from the :manpage:`truncate(2)`
324 system call, this can also be done through :manpage:`open(2)` with the flags
325 ``O_RDONLY | O_TRUNC``.
326
327 The truncate right is associated with the opened file (see below).
328
329 Rights associated with file descriptors
330 ---------------------------------------
331
332 When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` and
333 ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` rights is associated with the newly created
334 file descriptor and will be used for subsequent truncation and ioctl attempts
335 using :manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar
336 to opening a file for reading or writing, where permissions are checked during
337 :manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and
338 :manpage:`write(2)` calls.
339
340 As a consequence, it is possible that a process has multiple open file
341 descriptors referring to the same file, but Landlock enforces different things
342 when operating with these file descriptors. This can happen when a Landlock
343 ruleset gets enforced and the process keeps file descriptors which were opened
344 both before and after the enforcement. It is also possible to pass such file
345 descriptors between processes, keeping their Landlock properties, even when some
346 of the involved processes do not have an enforced Landlock ruleset.
347
348 Compatibility
349 =============
350
351 Backward and forward compatibility
352 ----------------------------------
353
354 Landlock is designed to be compatible with past and future versions of the
355 kernel. This is achieved thanks to the system call attributes and the
356 associated bitflags, particularly the ruleset's ``handled_access_fs``. Making
357 handled access right explicit enables the kernel and user space to have a clear
358 contract with each other. This is required to make sure sandboxing will not
359 get stricter with a system update, which could break applications.
360
361 Developers can subscribe to the `Landlock mailing list
362 <https://subspace.kernel.org/lists.linux.dev.html>`_ to knowingly update and
363 test their applications with the latest available features. In the interest of
364 users, and because they may use different kernel versions, it is strongly
365 encouraged to follow a best-effort security approach by checking the Landlock
366 ABI version at runtime and only enforcing the supported features.
367
368 .. _landlock_abi_versions:
369
370 Landlock ABI versions
371 ---------------------
372
373 The Landlock ABI version can be read with the sys_landlock_create_ruleset()
374 system call:
375
376 .. code-block:: c
377
378 int abi;
379
380 abi = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION);
381 if (abi < 0) {
382 switch (errno) {
383 case ENOSYS:
384 printf("Landlock is not supported by the current kernel.\n");
385 break;
386 case EOPNOTSUPP:
387 printf("Landlock is currently disabled.\n");
388 break;
389 }
390 return 0;
391 }
392 if (abi >= 2) {
393 printf("Landlock supports LANDLOCK_ACCESS_FS_REFER.\n");
394 }
395
396 The following kernel interfaces are implicitly supported by the first ABI
397 version. Features only supported from a specific version are explicitly marked
398 as such.
399
400 Kernel interface
401 ================
402
403 Access rights
404 -------------
405
406 .. kernel-doc:: include/uapi/linux/landlock.h
407 :identifiers: fs_access net_access
408
409 Creating a new ruleset
410 ----------------------
411
412 .. kernel-doc:: security/landlock/syscalls.c
413 :identifiers: sys_landlock_create_ruleset
414
415 .. kernel-doc:: include/uapi/linux/landlock.h
416 :identifiers: landlock_ruleset_attr
417
418 Extending a ruleset
419 -------------------
420
421 .. kernel-doc:: security/landlock/syscalls.c
422 :identifiers: sys_landlock_add_rule
423
424 .. kernel-doc:: include/uapi/linux/landlock.h
425 :identifiers: landlock_rule_type landlock_path_beneath_attr
426 landlock_net_port_attr
427
428 Enforcing a ruleset
429 -------------------
430
431 .. kernel-doc:: security/landlock/syscalls.c
432 :identifiers: sys_landlock_restrict_self
433
434 Current limitations
435 ===================
436
437 Filesystem topology modification
438 --------------------------------
439
440 Threads sandboxed with filesystem restrictions cannot modify filesystem
441 topology, whether via :manpage:`mount(2)` or :manpage:`pivot_root(2)`.
442 However, :manpage:`chroot(2)` calls are not denied.
443
444 Special filesystems
445 -------------------
446
447 Access to regular files and directories can be restricted by Landlock,
448 according to the handled accesses of a ruleset. However, files that do not
449 come from a user-visible filesystem (e.g. pipe, socket), but can still be
450 accessed through ``/proc/<pid>/fd/*``, cannot currently be explicitly
451 restricted. Likewise, some special kernel filesystems such as nsfs, which can
452 be accessed through ``/proc/<pid>/ns/*``, cannot currently be explicitly
453 restricted. However, thanks to the `ptrace restrictions`_, access to such
454 sensitive ``/proc`` files are automatically restricted according to domain
455 hierarchies. Future Landlock evolutions could still enable to explicitly
456 restrict such paths with dedicated ruleset flags.
457
458 Ruleset layers
459 --------------
460
461 There is a limit of 16 layers of stacked rulesets. This can be an issue for a
462 task willing to enforce a new ruleset in complement to its 16 inherited
463 rulesets. Once this limit is reached, sys_landlock_restrict_self() returns
464 E2BIG. It is then strongly suggested to carefully build rulesets once in the
465 life of a thread, especially for applications able to launch other applications
466 that may also want to sandbox themselves (e.g. shells, container managers,
467 etc.).
468
469 Memory usage
470 ------------
471
472 Kernel memory allocated to create rulesets is accounted and can be restricted
473 by the Documentation/admin-guide/cgroup-v1/memory.rst.
474
475 IOCTL support
476 -------------
477
478 The ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right restricts the use of
479 :manpage:`ioctl(2)`, but it only applies to *newly opened* device files. This
480 means specifically that pre-existing file descriptors like stdin, stdout and
481 stderr are unaffected.
482
483 Users should be aware that TTY devices have traditionally permitted to control
484 other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL
485 commands. Both of these require ``CAP_SYS_ADMIN`` on modern Linux systems, but
486 the behavior is configurable for ``TIOCSTI``.
487
488 On older systems, it is therefore recommended to close inherited TTY file
489 descriptors, or to reopen them from ``/proc/self/fd/*`` without the
490 ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right, if possible.
491
492 Landlock's IOCTL support is coarse-grained at the moment, but may become more
493 fine-grained in the future. Until then, users are advised to establish the
494 guarantees that they need through the file hierarchy, by only allowing the
495 ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right on files where it is really required.
496
497 Previous limitations
498 ====================
499
500 File renaming and linking (ABI < 2)
501 -----------------------------------
502
503 Because Landlock targets unprivileged access controls, it needs to properly
504 handle composition of rules. Such property also implies rules nesting.
505 Properly handling multiple layers of rulesets, each one of them able to
506 restrict access to files, also implies inheritance of the ruleset restrictions
507 from a parent to its hierarchy. Because files are identified and restricted by
508 their hierarchy, moving or linking a file from one directory to another implies
509 propagation of the hierarchy constraints, or restriction of these actions
510 according to the potentially lost constraints. To protect against privilege
511 escalations through renaming or linking, and for the sake of simplicity,
512 Landlock previously limited linking and renaming to the same directory.
513 Starting with the Landlock ABI version 2, it is now possible to securely
514 control renaming and linking thanks to the new ``LANDLOCK_ACCESS_FS_REFER``
515 access right.
516
517 File truncation (ABI < 3)
518 -------------------------
519
520 File truncation could not be denied before the third Landlock ABI, so it is
521 always allowed when using a kernel that only supports the first or second ABI.
522
523 Starting with the Landlock ABI version 3, it is now possible to securely control
524 truncation thanks to the new ``LANDLOCK_ACCESS_FS_TRUNCATE`` access right.
525
526 Network support (ABI < 4)
527 -------------------------
528
529 Starting with the Landlock ABI version 4, it is now possible to restrict TCP
530 bind and connect actions to only a set of allowed ports thanks to the new
531 ``LANDLOCK_ACCESS_NET_BIND_TCP`` and ``LANDLOCK_ACCESS_NET_CONNECT_TCP``
532 access rights.
533
534 IOCTL (ABI < 5)
535 ---------------
536
537 IOCTL operations could not be denied before the fifth Landlock ABI, so
538 :manpage:`ioctl(2)` is always allowed when using a kernel that only supports an
539 earlier ABI.
540
541 Starting with the Landlock ABI version 5, it is possible to restrict the use of
542 :manpage:`ioctl(2)` using the new ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right.
543
544 .. _kernel_support:
545
546 Kernel support
547 ==============
548
549 Build time configuration
550 ------------------------
551
552 Landlock was first introduced in Linux 5.13 but it must be configured at build
553 time with ``CONFIG_SECURITY_LANDLOCK=y``. Landlock must also be enabled at boot
554 time as the other security modules. The list of security modules enabled by
555 default is set with ``CONFIG_LSM``. The kernel configuration should then
556 contains ``CONFIG_LSM=landlock,[...]`` with ``[...]`` as the list of other
557 potentially useful security modules for the running system (see the
558 ``CONFIG_LSM`` help).
559
560 Boot time configuration
561 -----------------------
562
563 If the running kernel does not have ``landlock`` in ``CONFIG_LSM``, then we can
564 enable Landlock by adding ``lsm=landlock,[...]`` to
565 Documentation/admin-guide/kernel-parameters.rst in the boot loader
566 configuration.
567
568 For example, if the current built-in configuration is:
569
570 .. code-block:: console
571
572 $ zgrep -h "^CONFIG_LSM=" "/boot/config-$(uname -r)" /proc/config.gz 2>/dev/null
573 CONFIG_LSM="lockdown,yama,integrity,apparmor"
574
575 ...and if the cmdline doesn't contain ``landlock`` either:
576
577 .. code-block:: console
578
579 $ sed -n 's/.*\(\<lsm=\S\+\).*/\1/p' /proc/cmdline
580 lsm=lockdown,yama,integrity,apparmor
581
582 ...we should configure the boot loader to set a cmdline extending the ``lsm``
583 list with the ``landlock,`` prefix::
584
585 lsm=landlock,lockdown,yama,integrity,apparmor
586
587 After a reboot, we can check that Landlock is up and running by looking at
588 kernel logs:
589
590 .. code-block:: console
591
592 # dmesg | grep landlock || journalctl -kb -g landlock
593 [ 0.000000] Command line: [...] lsm=landlock,lockdown,yama,integrity,apparmor
594 [ 0.000000] Kernel command line: [...] lsm=landlock,lockdown,yama,integrity,apparmor
595 [ 0.000000] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor
596 [ 0.000000] landlock: Up and running.
597
598 The kernel may be configured at build time to always load the ``lockdown`` and
599 ``capability`` LSMs. In that case, these LSMs will appear at the beginning of
600 the ``LSM: initializing`` log line as well, even if they are not configured in
601 the boot loader.
602
603 Network support
604 ---------------
605
606 To be able to explicitly allow TCP operations (e.g., adding a network rule with
607 ``LANDLOCK_ACCESS_NET_BIND_TCP``), the kernel must support TCP
608 (``CONFIG_INET=y``). Otherwise, sys_landlock_add_rule() returns an
609 ``EAFNOSUPPORT`` error, which can safely be ignored because this kind of TCP
610 operation is already not possible.
611
612 Questions and answers
613 =====================
614
615 What about user space sandbox managers?
616 ---------------------------------------
617
618 Using user space process to enforce restrictions on kernel resources can lead
619 to race conditions or inconsistent evaluations (i.e. `Incorrect mirroring of
620 the OS code and state
621 <https://www.ndss-symposium.org/ndss2003/traps-and-pitfalls-practical-problems-system-call-interposition-based-security-tools/>`_).
622
623 What about namespaces and containers?
624 -------------------------------------
625
626 Namespaces can help create sandboxes but they are not designed for
627 access-control and then miss useful features for such use case (e.g. no
628 fine-grained restrictions). Moreover, their complexity can lead to security
629 issues, especially when untrusted processes can manipulate them (cf.
630 `Controlling access to user namespaces <https://lwn.net/Articles/673597/>`_).
631
632 Additional documentation
633 ========================
634
635 * Documentation/security/landlock.rst
636 * https://landlock.io
637
638 .. Links
639 .. _samples/landlock/sandboxer.c:
640 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.