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