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: January 2026 12 13The goal of Landlock is to enable restriction of ambient rights (e.g. global 14filesystem or network access) for a set of processes. Because Landlock 15is a stackable LSM, it makes it possible to create safe security sandboxes as 16new security layers in addition to the existing system-wide access-controls. 17This kind 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 .scoped = 85 LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | 86 LANDLOCK_SCOPE_SIGNAL, 87 }; 88 89Because we may not know which kernel version an application will be executed 90on, it is safer to follow a best-effort security approach. Indeed, we 91should try to protect users as much as possible whatever the kernel they are 92using. 93 94To be compatible with older Linux versions, we detect the available Landlock ABI 95version, and only use the available subset of access rights: 96 97.. code-block:: c 98 99 int abi; 100 101 abi = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION); 102 if (abi < 0) { 103 /* Degrades gracefully if Landlock is not handled. */ 104 perror("The running kernel does not enable to use Landlock"); 105 return 0; 106 } 107 switch (abi) { 108 case 1: 109 /* Removes LANDLOCK_ACCESS_FS_REFER for ABI < 2 */ 110 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_REFER; 111 __attribute__((fallthrough)); 112 case 2: 113 /* Removes LANDLOCK_ACCESS_FS_TRUNCATE for ABI < 3 */ 114 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_TRUNCATE; 115 __attribute__((fallthrough)); 116 case 3: 117 /* Removes network support for ABI < 4 */ 118 ruleset_attr.handled_access_net &= 119 ~(LANDLOCK_ACCESS_NET_BIND_TCP | 120 LANDLOCK_ACCESS_NET_CONNECT_TCP); 121 __attribute__((fallthrough)); 122 case 4: 123 /* Removes LANDLOCK_ACCESS_FS_IOCTL_DEV for ABI < 5 */ 124 ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_IOCTL_DEV; 125 __attribute__((fallthrough)); 126 case 5: 127 /* Removes LANDLOCK_SCOPE_* for ABI < 6 */ 128 ruleset_attr.scoped &= ~(LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | 129 LANDLOCK_SCOPE_SIGNAL); 130 } 131 132This enables the creation of an inclusive ruleset that will contain our rules. 133 134.. code-block:: c 135 136 int ruleset_fd; 137 138 ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0); 139 if (ruleset_fd < 0) { 140 perror("Failed to create a ruleset"); 141 return 1; 142 } 143 144We can now add a new rule to this ruleset thanks to the returned file 145descriptor referring to this ruleset. The rule will allow reading and 146executing the file hierarchy ``/usr``. Without another rule, write actions 147would then be denied by the ruleset. To add ``/usr`` to the ruleset, we open 148it with the ``O_PATH`` flag and fill the &struct landlock_path_beneath_attr with 149this file descriptor. 150 151.. code-block:: c 152 153 int err; 154 struct landlock_path_beneath_attr path_beneath = { 155 .allowed_access = 156 LANDLOCK_ACCESS_FS_EXECUTE | 157 LANDLOCK_ACCESS_FS_READ_FILE | 158 LANDLOCK_ACCESS_FS_READ_DIR, 159 }; 160 161 path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC); 162 if (path_beneath.parent_fd < 0) { 163 perror("Failed to open file"); 164 close(ruleset_fd); 165 return 1; 166 } 167 err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, 168 &path_beneath, 0); 169 close(path_beneath.parent_fd); 170 if (err) { 171 perror("Failed to update ruleset"); 172 close(ruleset_fd); 173 return 1; 174 } 175 176It may also be required to create rules following the same logic as explained 177for the ruleset creation, by filtering access rights according to the Landlock 178ABI version. In this example, this is not required because all of the requested 179``allowed_access`` rights are already available in ABI 1. 180 181For network access-control, we can add a set of rules that allow to use a port 182number for a specific action: HTTPS connections. 183 184.. code-block:: c 185 186 struct landlock_net_port_attr net_port = { 187 .allowed_access = LANDLOCK_ACCESS_NET_CONNECT_TCP, 188 .port = 443, 189 }; 190 191 err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT, 192 &net_port, 0); 193 194When passing a non-zero ``flags`` argument to ``landlock_restrict_self()``, a 195similar backwards compatibility check is needed for the restrict flags 196(see sys_landlock_restrict_self() documentation for available flags): 197 198.. code-block:: c 199 200 __u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON; 201 if (abi < 7) { 202 /* Clear logging flags unsupported before ABI 7. */ 203 restrict_flags &= ~(LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF | 204 LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON | 205 LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF); 206 } 207 208The next step is to restrict the current thread from gaining more privileges 209(e.g. through a SUID binary). We now have a ruleset with the first rule 210allowing read and execute access to ``/usr`` while denying all other handled 211accesses for the filesystem, and a second rule allowing HTTPS connections. 212 213.. code-block:: c 214 215 if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { 216 perror("Failed to restrict privileges"); 217 close(ruleset_fd); 218 return 1; 219 } 220 221The current thread is now ready to sandbox itself with the ruleset. 222 223.. code-block:: c 224 225 if (landlock_restrict_self(ruleset_fd, restrict_flags)) { 226 perror("Failed to enforce ruleset"); 227 close(ruleset_fd); 228 return 1; 229 } 230 close(ruleset_fd); 231 232If the ``landlock_restrict_self`` system call succeeds, the current thread is 233now restricted and this policy will be enforced on all its subsequently created 234children as well. Once a thread is landlocked, there is no way to remove its 235security policy; only adding more restrictions is allowed. These threads are 236now in a new Landlock domain, which is a merger of their parent one (if any) 237with the new ruleset. 238 239Full working code can be found in `samples/landlock/sandboxer.c`_. 240 241Good practices 242-------------- 243 244It is recommended to set access rights to file hierarchy leaves as much as 245possible. For instance, it is better to be able to have ``~/doc/`` as a 246read-only hierarchy and ``~/tmp/`` as a read-write hierarchy, compared to 247``~/`` as a read-only hierarchy and ``~/tmp/`` as a read-write hierarchy. 248Following this good practice leads to self-sufficient hierarchies that do not 249depend on their location (i.e. parent directories). This is particularly 250relevant when we want to allow linking or renaming. Indeed, having consistent 251access rights per directory enables changing the location of such directories 252without relying on the destination directory access rights (except those that 253are required for this operation, see ``LANDLOCK_ACCESS_FS_REFER`` 254documentation). 255 256Having self-sufficient hierarchies also helps to tighten the required access 257rights to the minimal set of data. This also helps avoid sinkhole directories, 258i.e. directories where data can be linked to but not linked from. However, 259this depends on data organization, which might not be controlled by developers. 260In this case, granting read-write access to ``~/tmp/``, instead of write-only 261access, would potentially allow moving ``~/tmp/`` to a non-readable directory 262and still keep the ability to list the content of ``~/tmp/``. 263 264Layers of file path access rights 265--------------------------------- 266 267Each time a thread enforces a ruleset on itself, it updates its Landlock domain 268with a new layer of policy. This complementary policy is stacked with any 269other rulesets potentially already restricting this thread. A sandboxed thread 270can then safely add more constraints to itself with a new enforced ruleset. 271 272One policy layer grants access to a file path if at least one of its rules 273encountered on the path grants the access. A sandboxed thread can only access 274a file path if all its enforced policy layers grant the access as well as all 275the other system access controls (e.g. filesystem DAC, other LSM policies, 276etc.). 277 278Bind mounts and OverlayFS 279------------------------- 280 281Landlock enables restricting access to file hierarchies, which means that these 282access rights can be propagated with bind mounts (cf. 283Documentation/filesystems/sharedsubtree.rst) but not with 284Documentation/filesystems/overlayfs.rst. 285 286A bind mount mirrors a source file hierarchy to a destination. The destination 287hierarchy is then composed of the exact same files, on which Landlock rules can 288be tied, either via the source or the destination path. These rules restrict 289access when they are encountered on a path, which means that they can restrict 290access to multiple file hierarchies at the same time, whether these hierarchies 291are the result of bind mounts or not. 292 293An OverlayFS mount point consists of upper and lower layers. These layers are 294combined in a merge directory, and that merged directory becomes available at 295the mount point. This merge hierarchy may include files from the upper and 296lower layers, but modifications performed on the merge hierarchy only reflect 297on the upper layer. From a Landlock policy point of view, all OverlayFS layers 298and merge hierarchies are standalone and each contains their own set of files 299and directories, which is different from bind mounts. A policy restricting an 300OverlayFS layer will not restrict the resulted merged hierarchy, and vice versa. 301Landlock users should then only think about file hierarchies they want to allow 302access to, regardless of the underlying filesystem. 303 304Inheritance 305----------- 306 307Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain 308restrictions from its parent. This is similar to seccomp inheritance (cf. 309Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with 310task's :manpage:`credentials(7)`. For instance, one process's thread may apply 311Landlock rules to itself, but they will not be automatically applied to other 312sibling threads (unlike POSIX thread credential changes, cf. 313:manpage:`nptl(7)`). 314 315When a thread sandboxes itself, we have the guarantee that the related security 316policy will stay enforced on all this thread's descendants. This allows 317creating standalone and modular security policies per application, which will 318automatically be composed between themselves according to their runtime parent 319policies. 320 321Ptrace restrictions 322------------------- 323 324A sandboxed process has less privileges than a non-sandboxed process and must 325then be subject to additional restrictions when manipulating another process. 326To be allowed to use :manpage:`ptrace(2)` and related syscalls on a target 327process, a sandboxed process should have a superset of the target process's 328access rights, which means the tracee must be in a sub-domain of the tracer. 329 330IPC scoping 331----------- 332 333Similar to the implicit `Ptrace restrictions`_, we may want to further restrict 334interactions between sandboxes. Therefore, at ruleset creation time, each 335Landlock domain can restrict the scope for certain operations, so that these 336operations can only reach out to processes within the same Landlock domain or in 337a nested Landlock domain (the "scope"). 338 339The operations which can be scoped are: 340 341``LANDLOCK_SCOPE_SIGNAL`` 342 This limits the sending of signals to target processes which run within the 343 same or a nested Landlock domain. 344 345``LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET`` 346 This limits the set of abstract :manpage:`unix(7)` sockets to which we can 347 :manpage:`connect(2)` to socket addresses which were created by a process in 348 the same or a nested Landlock domain. 349 350 A :manpage:`sendto(2)` on a non-connected datagram socket is treated as if 351 it were doing an implicit :manpage:`connect(2)` and will be blocked if the 352 remote end does not stem from the same or a nested Landlock domain. 353 354 A :manpage:`sendto(2)` on a socket which was previously connected will not 355 be restricted. This works for both datagram and stream sockets. 356 357IPC scoping does not support exceptions via :manpage:`landlock_add_rule(2)`. 358If an operation is scoped within a domain, no rules can be added to allow access 359to resources or processes outside of the scope. 360 361Truncating files 362---------------- 363 364The operations covered by ``LANDLOCK_ACCESS_FS_WRITE_FILE`` and 365``LANDLOCK_ACCESS_FS_TRUNCATE`` both change the contents of a file and sometimes 366overlap in non-intuitive ways. It is recommended to always specify both of 367these together. 368 369A particularly surprising example is :manpage:`creat(2)`. The name suggests 370that this system call requires the rights to create and write files. However, 371it also requires the truncate right if an existing file under the same name is 372already present. 373 374It should also be noted that truncating files does not require the 375``LANDLOCK_ACCESS_FS_WRITE_FILE`` right. Apart from the :manpage:`truncate(2)` 376system call, this can also be done through :manpage:`open(2)` with the flags 377``O_RDONLY | O_TRUNC``. 378 379The truncate right is associated with the opened file (see below). 380 381Rights associated with file descriptors 382--------------------------------------- 383 384When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` and 385``LANDLOCK_ACCESS_FS_IOCTL_DEV`` rights is associated with the newly created 386file descriptor and will be used for subsequent truncation and ioctl attempts 387using :manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar 388to opening a file for reading or writing, where permissions are checked during 389:manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and 390:manpage:`write(2)` calls. 391 392As a consequence, it is possible that a process has multiple open file 393descriptors referring to the same file, but Landlock enforces different things 394when operating with these file descriptors. This can happen when a Landlock 395ruleset gets enforced and the process keeps file descriptors which were opened 396both before and after the enforcement. It is also possible to pass such file 397descriptors between processes, keeping their Landlock properties, even when some 398of the involved processes do not have an enforced Landlock ruleset. 399 400Compatibility 401============= 402 403Backward and forward compatibility 404---------------------------------- 405 406Landlock is designed to be compatible with past and future versions of the 407kernel. This is achieved thanks to the system call attributes and the 408associated bitflags, particularly the ruleset's ``handled_access_fs``. Making 409handled access rights explicit enables the kernel and user space to have a clear 410contract with each other. This is required to make sure sandboxing will not 411get stricter with a system update, which could break applications. 412 413Developers can subscribe to the `Landlock mailing list 414<https://subspace.kernel.org/lists.linux.dev.html>`_ to knowingly update and 415test their applications with the latest available features. In the interest of 416users, and because they may use different kernel versions, it is strongly 417encouraged to follow a best-effort security approach by checking the Landlock 418ABI version at runtime and only enforcing the supported features. 419 420.. _landlock_abi_versions: 421 422Landlock ABI versions 423--------------------- 424 425The Landlock ABI version can be read with the sys_landlock_create_ruleset() 426system call: 427 428.. code-block:: c 429 430 int abi; 431 432 abi = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION); 433 if (abi < 0) { 434 switch (errno) { 435 case ENOSYS: 436 printf("Landlock is not supported by the current kernel.\n"); 437 break; 438 case EOPNOTSUPP: 439 printf("Landlock is currently disabled.\n"); 440 break; 441 } 442 return 0; 443 } 444 if (abi >= 2) { 445 printf("Landlock supports LANDLOCK_ACCESS_FS_REFER.\n"); 446 } 447 448All Landlock kernel interfaces are supported by the first ABI version unless 449explicitly noted in their documentation. 450 451Landlock errata 452--------------- 453 454In addition to ABI versions, Landlock provides an errata mechanism to track 455fixes for issues that may affect backwards compatibility or require userspace 456awareness. The errata bitmask can be queried using: 457 458.. code-block:: c 459 460 int errata; 461 462 errata = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_ERRATA); 463 if (errata < 0) { 464 /* Landlock not available or disabled */ 465 return 0; 466 } 467 468The returned value is a bitmask where each bit represents a specific erratum. 469If bit N is set (``errata & (1 << (N - 1))``), then erratum N has been fixed 470in the running kernel. 471 472.. warning:: 473 474 **Most applications should NOT check errata.** In 99.9% of cases, checking 475 errata is unnecessary, increases code complexity, and can potentially 476 decrease protection if misused. For example, disabling the sandbox when an 477 erratum is not fixed could leave the system less secure than using 478 Landlock's best-effort protection. When in doubt, ignore errata. 479 480.. kernel-doc:: security/landlock/errata/abi-4.h 481 :doc: erratum_1 482 483.. kernel-doc:: security/landlock/errata/abi-6.h 484 :doc: erratum_2 485 486.. kernel-doc:: security/landlock/errata/abi-1.h 487 :doc: erratum_3 488 489How to check for errata 490~~~~~~~~~~~~~~~~~~~~~~~ 491 492If you determine that your application needs to check for specific errata, 493use this pattern: 494 495.. code-block:: c 496 497 int errata = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_ERRATA); 498 if (errata >= 0) { 499 /* Check for specific erratum (1-indexed) */ 500 if (errata & (1 << (erratum_number - 1))) { 501 /* Erratum N is fixed in this kernel */ 502 } else { 503 /* Erratum N is NOT fixed - consider implications for your use case */ 504 } 505 } 506 507**Important:** Only check errata if your application specifically relies on 508behavior that changed due to the fix. The fixes generally make Landlock less 509restrictive or more correct, not more restrictive. 510 511Kernel interface 512================ 513 514Access rights 515------------- 516 517.. kernel-doc:: include/uapi/linux/landlock.h 518 :identifiers: fs_access net_access scope 519 520Creating a new ruleset 521---------------------- 522 523.. kernel-doc:: security/landlock/syscalls.c 524 :identifiers: sys_landlock_create_ruleset 525 526.. kernel-doc:: include/uapi/linux/landlock.h 527 :identifiers: landlock_ruleset_attr 528 529Extending a ruleset 530------------------- 531 532.. kernel-doc:: security/landlock/syscalls.c 533 :identifiers: sys_landlock_add_rule 534 535.. kernel-doc:: include/uapi/linux/landlock.h 536 :identifiers: landlock_rule_type landlock_path_beneath_attr 537 landlock_net_port_attr 538 539Enforcing a ruleset 540------------------- 541 542.. kernel-doc:: security/landlock/syscalls.c 543 :identifiers: sys_landlock_restrict_self 544 545Current limitations 546=================== 547 548Filesystem topology modification 549-------------------------------- 550 551Threads sandboxed with filesystem restrictions cannot modify filesystem 552topology, whether via :manpage:`mount(2)` or :manpage:`pivot_root(2)`. 553However, :manpage:`chroot(2)` calls are not denied. 554 555Special filesystems 556------------------- 557 558Access to regular files and directories can be restricted by Landlock, 559according to the handled accesses of a ruleset. However, files that do not 560come from a user-visible filesystem (e.g. pipe, socket), but can still be 561accessed through ``/proc/<pid>/fd/*``, cannot currently be explicitly 562restricted. Likewise, some special kernel filesystems such as nsfs, which can 563be accessed through ``/proc/<pid>/ns/*``, cannot currently be explicitly 564restricted. However, thanks to the `ptrace restrictions`_, access to such 565sensitive ``/proc`` files are automatically restricted according to domain 566hierarchies. Future Landlock evolutions could still enable to explicitly 567restrict such paths with dedicated ruleset flags. 568 569Ruleset layers 570-------------- 571 572There is a limit of 16 layers of stacked rulesets. This can be an issue for a 573task willing to enforce a new ruleset in complement to its 16 inherited 574rulesets. Once this limit is reached, sys_landlock_restrict_self() returns 575E2BIG. It is then strongly suggested to carefully build rulesets once in the 576life of a thread, especially for applications able to launch other applications 577that may also want to sandbox themselves (e.g. shells, container managers, 578etc.). 579 580Memory usage 581------------ 582 583Kernel memory allocated to create rulesets is accounted and can be restricted 584by the Documentation/admin-guide/cgroup-v1/memory.rst. 585 586IOCTL support 587------------- 588 589The ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right restricts the use of 590:manpage:`ioctl(2)`, but it only applies to *newly opened* device files. This 591means specifically that pre-existing file descriptors like stdin, stdout and 592stderr are unaffected. 593 594Users should be aware that TTY devices have traditionally permitted to control 595other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL 596commands. Both of these require ``CAP_SYS_ADMIN`` on modern Linux systems, but 597the behavior is configurable for ``TIOCSTI``. 598 599On older systems, it is therefore recommended to close inherited TTY file 600descriptors, or to reopen them from ``/proc/self/fd/*`` without the 601``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right, if possible. 602 603Landlock's IOCTL support is coarse-grained at the moment, but may become more 604fine-grained in the future. Until then, users are advised to establish the 605guarantees that they need through the file hierarchy, by only allowing the 606``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right on files where it is really required. 607 608Previous limitations 609==================== 610 611File renaming and linking (ABI < 2) 612----------------------------------- 613 614Because Landlock targets unprivileged access controls, it needs to properly 615handle composition of rules. Such property also implies rules nesting. 616Properly handling multiple layers of rulesets, each one of them able to 617restrict access to files, also implies inheritance of the ruleset restrictions 618from a parent to its hierarchy. Because files are identified and restricted by 619their hierarchy, moving or linking a file from one directory to another implies 620propagation of the hierarchy constraints, or restriction of these actions 621according to the potentially lost constraints. To protect against privilege 622escalations through renaming or linking, and for the sake of simplicity, 623Landlock previously limited linking and renaming to the same directory. 624Starting with the Landlock ABI version 2, it is now possible to securely 625control renaming and linking thanks to the new ``LANDLOCK_ACCESS_FS_REFER`` 626access right. 627 628File truncation (ABI < 3) 629------------------------- 630 631File truncation could not be denied before the third Landlock ABI, so it is 632always allowed when using a kernel that only supports the first or second ABI. 633 634Starting with the Landlock ABI version 3, it is now possible to securely control 635truncation thanks to the new ``LANDLOCK_ACCESS_FS_TRUNCATE`` access right. 636 637TCP bind and connect (ABI < 4) 638------------------------------ 639 640Starting with the Landlock ABI version 4, it is now possible to restrict TCP 641bind and connect actions to only a set of allowed ports thanks to the new 642``LANDLOCK_ACCESS_NET_BIND_TCP`` and ``LANDLOCK_ACCESS_NET_CONNECT_TCP`` 643access rights. 644 645Device IOCTL (ABI < 5) 646---------------------- 647 648IOCTL operations could not be denied before the fifth Landlock ABI, so 649:manpage:`ioctl(2)` is always allowed when using a kernel that only supports an 650earlier ABI. 651 652Starting with the Landlock ABI version 5, it is possible to restrict the use of 653:manpage:`ioctl(2)` on character and block devices using the new 654``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right. 655 656Abstract UNIX socket (ABI < 6) 657------------------------------ 658 659Starting with the Landlock ABI version 6, it is possible to restrict 660connections to an abstract :manpage:`unix(7)` socket by setting 661``LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET`` to the ``scoped`` ruleset attribute. 662 663Signal (ABI < 6) 664---------------- 665 666Starting with the Landlock ABI version 6, it is possible to restrict 667:manpage:`signal(7)` sending by setting ``LANDLOCK_SCOPE_SIGNAL`` to the 668``scoped`` ruleset attribute. 669 670Logging (ABI < 7) 671----------------- 672 673Starting with the Landlock ABI version 7, it is possible to control logging of 674Landlock audit events with the ``LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF``, 675``LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON``, and 676``LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF`` flags passed to 677sys_landlock_restrict_self(). See Documentation/admin-guide/LSM/landlock.rst 678for more details on audit. 679 680Thread synchronization (ABI < 8) 681-------------------------------- 682 683Starting with the Landlock ABI version 8, it is now possible to 684enforce Landlock rulesets across all threads of the calling process 685using the ``LANDLOCK_RESTRICT_SELF_TSYNC`` flag passed to 686sys_landlock_restrict_self(). 687 688.. _kernel_support: 689 690Kernel support 691============== 692 693Build time configuration 694------------------------ 695 696Landlock was first introduced in Linux 5.13 but it must be configured at build 697time with ``CONFIG_SECURITY_LANDLOCK=y``. Landlock must also be enabled at boot 698time like other security modules. The list of security modules enabled by 699default is set with ``CONFIG_LSM``. The kernel configuration should then 700contain ``CONFIG_LSM=landlock,[...]`` with ``[...]`` as the list of other 701potentially useful security modules for the running system (see the 702``CONFIG_LSM`` help). 703 704Boot time configuration 705----------------------- 706 707If the running kernel does not have ``landlock`` in ``CONFIG_LSM``, then we can 708enable Landlock by adding ``lsm=landlock,[...]`` to 709Documentation/admin-guide/kernel-parameters.rst in the boot loader 710configuration. 711 712For example, if the current built-in configuration is: 713 714.. code-block:: console 715 716 $ zgrep -h "^CONFIG_LSM=" "/boot/config-$(uname -r)" /proc/config.gz 2>/dev/null 717 CONFIG_LSM="lockdown,yama,integrity,apparmor" 718 719...and if the cmdline doesn't contain ``landlock`` either: 720 721.. code-block:: console 722 723 $ sed -n 's/.*\(\<lsm=\S\+\).*/\1/p' /proc/cmdline 724 lsm=lockdown,yama,integrity,apparmor 725 726...we should configure the boot loader to set a cmdline extending the ``lsm`` 727list with the ``landlock,`` prefix:: 728 729 lsm=landlock,lockdown,yama,integrity,apparmor 730 731After a reboot, we can check that Landlock is up and running by looking at 732kernel logs: 733 734.. code-block:: console 735 736 # dmesg | grep landlock || journalctl -kb -g landlock 737 [ 0.000000] Command line: [...] lsm=landlock,lockdown,yama,integrity,apparmor 738 [ 0.000000] Kernel command line: [...] lsm=landlock,lockdown,yama,integrity,apparmor 739 [ 0.000000] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor 740 [ 0.000000] landlock: Up and running. 741 742The kernel may be configured at build time to always load the ``lockdown`` and 743``capability`` LSMs. In that case, these LSMs will appear at the beginning of 744the ``LSM: initializing`` log line as well, even if they are not configured in 745the boot loader. 746 747Network support 748--------------- 749 750To be able to explicitly allow TCP operations (e.g., adding a network rule with 751``LANDLOCK_ACCESS_NET_BIND_TCP``), the kernel must support TCP 752(``CONFIG_INET=y``). Otherwise, sys_landlock_add_rule() returns an 753``EAFNOSUPPORT`` error, which can safely be ignored because this kind of TCP 754operation is already not possible. 755 756Questions and answers 757===================== 758 759What about user space sandbox managers? 760--------------------------------------- 761 762Using user space processes to enforce restrictions on kernel resources can lead 763to race conditions or inconsistent evaluations (i.e. `Incorrect mirroring of 764the OS code and state 765<https://www.ndss-symposium.org/ndss2003/traps-and-pitfalls-practical-problems-system-call-interposition-based-security-tools/>`_). 766 767What about namespaces and containers? 768------------------------------------- 769 770Namespaces can help create sandboxes but they are not designed for 771access-control and then miss useful features for such use case (e.g. no 772fine-grained restrictions). Moreover, their complexity can lead to security 773issues, especially when untrusted processes can manipulate them (cf. 774`Controlling access to user namespaces <https://lwn.net/Articles/673597/>`_). 775 776How to disable Landlock audit records? 777-------------------------------------- 778 779You might want to put in place filters as explained here: 780Documentation/admin-guide/LSM/landlock.rst 781 782Additional documentation 783======================== 784 785* Documentation/admin-guide/LSM/landlock.rst 786* Documentation/security/landlock.rst 787* https://landlock.io 788 789.. Links 790.. _samples/landlock/sandboxer.c: 791 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c 792