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===================================== 7Landlock: unprivileged access control 8===================================== 9 10:Author: Mickaël Salaün 11:Date: July 2024 12 13The goal of Landlock is to enable to restrict ambient rights (e.g. global 14filesystem or network access) for a set of processes. Because Landlock 15is a stackable LSM, it makes possible to create safe security sandboxes as new 16security layers in addition to the existing system-wide access-controls. This 17kind of sandbox is expected to help mitigate the security impact of bugs or 18unexpected/malicious behaviors in user space applications. Landlock empowers 19any process, including unprivileged ones, to securely restrict themselves. 20 21We can quickly make sure that Landlock is enabled in the running system by 22looking for "landlock: Up and running" in kernel logs (as root): 23``dmesg | grep landlock || journalctl -kb -g landlock`` . 24Developers can also easily check for Landlock support with a 25:ref:`related system call <landlock_abi_versions>`. 26If Landlock is not currently supported, we need to 27:ref:`configure the kernel appropriately <kernel_support>`. 28 29Landlock rules 30============== 31 32A Landlock rule describes an action on an object which the process intends to 33perform. A set of rules is aggregated in a ruleset, which can then restrict 34the thread enforcing it, and its future children. 35 36The two existing types of rules are: 37 38Filesystem 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 43Network 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 47Defining and enforcing a security policy 48---------------------------------------- 49 50We first need to define the ruleset that will contain our rules. 51 52For this example, the ruleset will contain rules that only allow filesystem 53read actions and establish a specific TCP connection. Filesystem write 54actions and other TCP actions will be denied. 55 56The ruleset then needs to handle both these kinds of actions. This is 57required for backward and forward compatibility (i.e. the kernel and user 58space may not know each other's supported restrictions), hence the need 59to 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 86Because we may not know on which kernel version an application will be 87executed, it is safer to follow a best-effort security approach. Indeed, we 88should try to protect users as much as possible whatever the kernel they are 89using. 90 91To be compatible with older Linux versions, we detect the available Landlock ABI 92version, 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 124This 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 136We can now add a new rule to this ruleset thanks to the returned file 137descriptor referring to this ruleset. The rule will only allow reading the 138file hierarchy ``/usr``. Without another rule, write actions would then be 139denied 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 141descriptor. 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 168It may also be required to create rules following the same logic as explained 169for the ruleset creation, by filtering access rights according to the Landlock 170ABI version. In this example, this is not required because all of the requested 171``allowed_access`` rights are already available in ABI 1. 172 173For network access-control, we can add a set of rules that allow to use a port 174number 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 186The 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 188allowing read access to ``/usr`` while denying all other handled accesses for 189the 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 199The 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 210If the ``landlock_restrict_self`` system call succeeds, the current thread is 211now restricted and this policy will be enforced on all its subsequently created 212children as well. Once a thread is landlocked, there is no way to remove its 213security policy; only adding more restrictions is allowed. These threads are 214now in a new Landlock domain, merge of their parent one (if any) with the new 215ruleset. 216 217Full working code can be found in `samples/landlock/sandboxer.c`_. 218 219Good practices 220-------------- 221 222It is recommended setting access rights to file hierarchy leaves as much as 223possible. For instance, it is better to be able to have ``~/doc/`` as a 224read-only hierarchy and ``~/tmp/`` as a read-write hierarchy, compared to 225``~/`` as a read-only hierarchy and ``~/tmp/`` as a read-write hierarchy. 226Following this good practice leads to self-sufficient hierarchies that do not 227depend on their location (i.e. parent directories). This is particularly 228relevant when we want to allow linking or renaming. Indeed, having consistent 229access rights per directory enables to change the location of such directory 230without relying on the destination directory access rights (except those that 231are required for this operation, see ``LANDLOCK_ACCESS_FS_REFER`` 232documentation). 233 234Having self-sufficient hierarchies also helps to tighten the required access 235rights to the minimal set of data. This also helps avoid sinkhole directories, 236i.e. directories where data can be linked to but not linked from. However, 237this depends on data organization, which might not be controlled by developers. 238In this case, granting read-write access to ``~/tmp/``, instead of write-only 239access, would potentially allow to move ``~/tmp/`` to a non-readable directory 240and still keep the ability to list the content of ``~/tmp/``. 241 242Layers of file path access rights 243--------------------------------- 244 245Each time a thread enforces a ruleset on itself, it updates its Landlock domain 246with a new layer of policy. Indeed, this complementary policy is stacked with 247the potentially other rulesets already restricting this thread. A sandboxed 248thread can then safely add more constraints to itself with a new enforced 249ruleset. 250 251One policy layer grants access to a file path if at least one of its rules 252encountered on the path grants the access. A sandboxed thread can only access 253a file path if all its enforced policy layers grant the access as well as all 254the other system access controls (e.g. filesystem DAC, other LSM policies, 255etc.). 256 257Bind mounts and OverlayFS 258------------------------- 259 260Landlock enables to restrict access to file hierarchies, which means that these 261access rights can be propagated with bind mounts (cf. 262Documentation/filesystems/sharedsubtree.rst) but not with 263Documentation/filesystems/overlayfs.rst. 264 265A bind mount mirrors a source file hierarchy to a destination. The destination 266hierarchy is then composed of the exact same files, on which Landlock rules can 267be tied, either via the source or the destination path. These rules restrict 268access when they are encountered on a path, which means that they can restrict 269access to multiple file hierarchies at the same time, whether these hierarchies 270are the result of bind mounts or not. 271 272An OverlayFS mount point consists of upper and lower layers. These layers are 273combined in a merge directory, result of the mount point. This merge hierarchy 274may include files from the upper and lower layers, but modifications performed 275on the merge hierarchy only reflects on the upper layer. From a Landlock 276policy point of view, each OverlayFS layers and merge hierarchies are 277standalone and contains their own set of files and directories, which is 278different from bind mounts. A policy restricting an OverlayFS layer will not 279restrict the resulted merged hierarchy, and vice versa. Landlock users should 280then only think about file hierarchies they want to allow access to, regardless 281of the underlying filesystem. 282 283Inheritance 284----------- 285 286Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain 287restrictions from its parent. This is similar to the seccomp inheritance (cf. 288Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with 289task's :manpage:`credentials(7)`. For instance, one process's thread may apply 290Landlock rules to itself, but they will not be automatically applied to other 291sibling threads (unlike POSIX thread credential changes, cf. 292:manpage:`nptl(7)`). 293 294When a thread sandboxes itself, we have the guarantee that the related security 295policy will stay enforced on all this thread's descendants. This allows 296creating standalone and modular security policies per application, which will 297automatically be composed between themselves according to their runtime parent 298policies. 299 300Ptrace restrictions 301------------------- 302 303A sandboxed process has less privileges than a non-sandboxed process and must 304then be subject to additional restrictions when manipulating another process. 305To be allowed to use :manpage:`ptrace(2)` and related syscalls on a target 306process, a sandboxed process should have a subset of the target process rules, 307which means the tracee must be in a sub-domain of the tracer. 308 309Truncating files 310---------------- 311 312The operations covered by ``LANDLOCK_ACCESS_FS_WRITE_FILE`` and 313``LANDLOCK_ACCESS_FS_TRUNCATE`` both change the contents of a file and sometimes 314overlap in non-intuitive ways. It is recommended to always specify both of 315these together. 316 317A particularly surprising example is :manpage:`creat(2)`. The name suggests 318that this system call requires the rights to create and write files. However, 319it also requires the truncate right if an existing file under the same name is 320already present. 321 322It should also be noted that truncating files does not require the 323``LANDLOCK_ACCESS_FS_WRITE_FILE`` right. Apart from the :manpage:`truncate(2)` 324system call, this can also be done through :manpage:`open(2)` with the flags 325``O_RDONLY | O_TRUNC``. 326 327The truncate right is associated with the opened file (see below). 328 329Rights associated with file descriptors 330--------------------------------------- 331 332When 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 334file descriptor and will be used for subsequent truncation and ioctl attempts 335using :manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar 336to 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 340As a consequence, it is possible that a process has multiple open file 341descriptors referring to the same file, but Landlock enforces different things 342when operating with these file descriptors. This can happen when a Landlock 343ruleset gets enforced and the process keeps file descriptors which were opened 344both before and after the enforcement. It is also possible to pass such file 345descriptors between processes, keeping their Landlock properties, even when some 346of the involved processes do not have an enforced Landlock ruleset. 347 348Compatibility 349============= 350 351Backward and forward compatibility 352---------------------------------- 353 354Landlock is designed to be compatible with past and future versions of the 355kernel. This is achieved thanks to the system call attributes and the 356associated bitflags, particularly the ruleset's ``handled_access_fs``. Making 357handled access right explicit enables the kernel and user space to have a clear 358contract with each other. This is required to make sure sandboxing will not 359get stricter with a system update, which could break applications. 360 361Developers can subscribe to the `Landlock mailing list 362<https://subspace.kernel.org/lists.linux.dev.html>`_ to knowingly update and 363test their applications with the latest available features. In the interest of 364users, and because they may use different kernel versions, it is strongly 365encouraged to follow a best-effort security approach by checking the Landlock 366ABI version at runtime and only enforcing the supported features. 367 368.. _landlock_abi_versions: 369 370Landlock ABI versions 371--------------------- 372 373The Landlock ABI version can be read with the sys_landlock_create_ruleset() 374system 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 396The following kernel interfaces are implicitly supported by the first ABI 397version. Features only supported from a specific version are explicitly marked 398as such. 399 400Kernel interface 401================ 402 403Access rights 404------------- 405 406.. kernel-doc:: include/uapi/linux/landlock.h 407 :identifiers: fs_access net_access 408 409Creating 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 418Extending 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 428Enforcing a ruleset 429------------------- 430 431.. kernel-doc:: security/landlock/syscalls.c 432 :identifiers: sys_landlock_restrict_self 433 434Current limitations 435=================== 436 437Filesystem topology modification 438-------------------------------- 439 440Threads sandboxed with filesystem restrictions cannot modify filesystem 441topology, whether via :manpage:`mount(2)` or :manpage:`pivot_root(2)`. 442However, :manpage:`chroot(2)` calls are not denied. 443 444Special filesystems 445------------------- 446 447Access to regular files and directories can be restricted by Landlock, 448according to the handled accesses of a ruleset. However, files that do not 449come from a user-visible filesystem (e.g. pipe, socket), but can still be 450accessed through ``/proc/<pid>/fd/*``, cannot currently be explicitly 451restricted. Likewise, some special kernel filesystems such as nsfs, which can 452be accessed through ``/proc/<pid>/ns/*``, cannot currently be explicitly 453restricted. However, thanks to the `ptrace restrictions`_, access to such 454sensitive ``/proc`` files are automatically restricted according to domain 455hierarchies. Future Landlock evolutions could still enable to explicitly 456restrict such paths with dedicated ruleset flags. 457 458Ruleset layers 459-------------- 460 461There is a limit of 16 layers of stacked rulesets. This can be an issue for a 462task willing to enforce a new ruleset in complement to its 16 inherited 463rulesets. Once this limit is reached, sys_landlock_restrict_self() returns 464E2BIG. It is then strongly suggested to carefully build rulesets once in the 465life of a thread, especially for applications able to launch other applications 466that may also want to sandbox themselves (e.g. shells, container managers, 467etc.). 468 469Memory usage 470------------ 471 472Kernel memory allocated to create rulesets is accounted and can be restricted 473by the Documentation/admin-guide/cgroup-v1/memory.rst. 474 475IOCTL support 476------------- 477 478The ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right restricts the use of 479:manpage:`ioctl(2)`, but it only applies to *newly opened* device files. This 480means specifically that pre-existing file descriptors like stdin, stdout and 481stderr are unaffected. 482 483Users should be aware that TTY devices have traditionally permitted to control 484other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL 485commands. Both of these require ``CAP_SYS_ADMIN`` on modern Linux systems, but 486the behavior is configurable for ``TIOCSTI``. 487 488On older systems, it is therefore recommended to close inherited TTY file 489descriptors, or to reopen them from ``/proc/self/fd/*`` without the 490``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right, if possible. 491 492Landlock's IOCTL support is coarse-grained at the moment, but may become more 493fine-grained in the future. Until then, users are advised to establish the 494guarantees 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 497Previous limitations 498==================== 499 500File renaming and linking (ABI < 2) 501----------------------------------- 502 503Because Landlock targets unprivileged access controls, it needs to properly 504handle composition of rules. Such property also implies rules nesting. 505Properly handling multiple layers of rulesets, each one of them able to 506restrict access to files, also implies inheritance of the ruleset restrictions 507from a parent to its hierarchy. Because files are identified and restricted by 508their hierarchy, moving or linking a file from one directory to another implies 509propagation of the hierarchy constraints, or restriction of these actions 510according to the potentially lost constraints. To protect against privilege 511escalations through renaming or linking, and for the sake of simplicity, 512Landlock previously limited linking and renaming to the same directory. 513Starting with the Landlock ABI version 2, it is now possible to securely 514control renaming and linking thanks to the new ``LANDLOCK_ACCESS_FS_REFER`` 515access right. 516 517File truncation (ABI < 3) 518------------------------- 519 520File truncation could not be denied before the third Landlock ABI, so it is 521always allowed when using a kernel that only supports the first or second ABI. 522 523Starting with the Landlock ABI version 3, it is now possible to securely control 524truncation thanks to the new ``LANDLOCK_ACCESS_FS_TRUNCATE`` access right. 525 526Network support (ABI < 4) 527------------------------- 528 529Starting with the Landlock ABI version 4, it is now possible to restrict TCP 530bind 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`` 532access rights. 533 534IOCTL (ABI < 5) 535--------------- 536 537IOCTL 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 539earlier ABI. 540 541Starting 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 546Kernel support 547============== 548 549Build time configuration 550------------------------ 551 552Landlock was first introduced in Linux 5.13 but it must be configured at build 553time with ``CONFIG_SECURITY_LANDLOCK=y``. Landlock must also be enabled at boot 554time as the other security modules. The list of security modules enabled by 555default is set with ``CONFIG_LSM``. The kernel configuration should then 556contains ``CONFIG_LSM=landlock,[...]`` with ``[...]`` as the list of other 557potentially useful security modules for the running system (see the 558``CONFIG_LSM`` help). 559 560Boot time configuration 561----------------------- 562 563If the running kernel does not have ``landlock`` in ``CONFIG_LSM``, then we can 564enable Landlock by adding ``lsm=landlock,[...]`` to 565Documentation/admin-guide/kernel-parameters.rst in the boot loader 566configuration. 567 568For 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`` 583list with the ``landlock,`` prefix:: 584 585 lsm=landlock,lockdown,yama,integrity,apparmor 586 587After a reboot, we can check that Landlock is up and running by looking at 588kernel 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 598The 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 600the ``LSM: initializing`` log line as well, even if they are not configured in 601the boot loader. 602 603Network support 604--------------- 605 606To 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 610operation is already not possible. 611 612Questions and answers 613===================== 614 615What about user space sandbox managers? 616--------------------------------------- 617 618Using user space process to enforce restrictions on kernel resources can lead 619to race conditions or inconsistent evaluations (i.e. `Incorrect mirroring of 620the OS code and state 621<https://www.ndss-symposium.org/ndss2003/traps-and-pitfalls-practical-problems-system-call-interposition-based-security-tools/>`_). 622 623What about namespaces and containers? 624------------------------------------- 625 626Namespaces can help create sandboxes but they are not designed for 627access-control and then miss useful features for such use case (e.g. no 628fine-grained restrictions). Moreover, their complexity can lead to security 629issues, especially when untrusted processes can manipulate them (cf. 630`Controlling access to user namespaces <https://lwn.net/Articles/673597/>`_). 631 632Additional 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 641