{ "mode": "man", "parameter": "landlock", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/landlock/7/json", "generated": "2026-10-04T18:10:34Z", "sections": { "NAME": { "content": "Landlock - unprivileged access-control\n", "subsections": [] }, "DESCRIPTION": { "content": "Landlock is an access-control system that enables any processes to securely restrict them‐\nselves and their future children. Because Landlock is a stackable Linux Security Module\n(LSM), it makes it possible to create safe security sandboxes as new security layers in addi‐\ntion to the existing system-wide access-controls. This kind of sandbox is expected to help\nmitigate the security impact of bugs, and unexpected or malicious behaviors in applications.\n\nA Landlock security policy is a set of access rights (e.g., open a file in read-only, make a\ndirectory, etc.) tied to a file hierarchy. Such policy can be configured and enforced by\nprocesses for themselves using three system calls:\n\n• landlockcreateruleset(2) creates a new ruleset;\n\n• landlockaddrule(2) adds a new rule to a ruleset;\n\n• landlockrestrictself(2) enforces a ruleset on the calling thread.\n\nTo be able to use these system calls, the running kernel must support Landlock and it must be\nenabled at boot time.\n", "subsections": [ { "name": "Landlock rules", "content": "A Landlock rule describes an action on an object. An object is currently a file hierarchy,\nand the related filesystem actions are defined with access rights (see landlockaddrule(2)).\nA set of rules is aggregated in a ruleset, which can then restrict the thread enforcing it,\nand its future children.\n" }, { "name": "Filesystem actions", "content": "These flags enable to restrict a sandboxed process to a set of actions on files and directo‐\nries. Files or directories opened before the sandboxing are not subject to these restric‐\ntions. See landlockaddrule(2) and landlockcreateruleset(2) for more context.\n\nA file can only receive these access rights:\n\nLANDLOCKACCESSFSEXECUTE\nExecute a file.\n\nLANDLOCKACCESSFSWRITEFILE\nOpen a file with write access.\n\nWhen opening files for writing, you will often additionally need the LANDLOCKAC‐\nCESSFSTRUNCATE right. In many cases, these system calls truncate existing files\nwhen overwriting them (e.g., creat(2)).\n\nLANDLOCKACCESSFSREADFILE\nOpen a file with read access.\n\nLANDLOCKACCESSFSTRUNCATE\nTruncate a file with truncate(2), ftruncate(2), creat(2), or open(2) with OTRUNC.\nWhether an opened file can be truncated with ftruncate(2) is determined during\nopen(2), in the same way as read and write permissions are checked during open(2) us‐\ning LANDLOCKACCESSFSREADFILE and LANDLOCKACCESSFSWRITEFILE. This access right\nis available since the third version of the Landlock ABI.\n\nA directory can receive access rights related to files or directories. The following access\nright is applied to the directory itself, and the directories beneath it:\n\nLANDLOCKACCESSFSREADDIR\nOpen a directory or list its content.\n\nHowever, the following access rights only apply to the content of a directory, not the direc‐\ntory itself:\n\nLANDLOCKACCESSFSREMOVEDIR\nRemove an empty directory or rename one.\n\nLANDLOCKACCESSFSREMOVEFILE\nUnlink (or rename) a file.\n\nLANDLOCKACCESSFSMAKECHAR\nCreate (or rename or link) a character device.\n\nLANDLOCKACCESSFSMAKEDIR\nCreate (or rename) a directory.\n\nLANDLOCKACCESSFSMAKEREG\nCreate (or rename or link) a regular file.\n\nLANDLOCKACCESSFSMAKESOCK\nCreate (or rename or link) a UNIX domain socket.\n\nLANDLOCKACCESSFSMAKEFIFO\nCreate (or rename or link) a named pipe.\n\nLANDLOCKACCESSFSMAKEBLOCK\nCreate (or rename or link) a block device.\n\nLANDLOCKACCESSFSMAKESYM\nCreate (or rename or link) a symbolic link.\n\nLANDLOCKACCESSFSREFER\nLink or rename a file from or to a different directory (i.e., reparent a file hierar‐\nchy).\n\nThis access right is available since the second version of the Landlock ABI.\n\nThis is the only access right which is denied by default by any ruleset, even if the\nright is not specified as handled at ruleset creation time. The only way to make a\nruleset grant this right is to explicitly allow it for a specific directory by adding\na matching rule to the ruleset.\n\nIn particular, when using the first Landlock ABI version, Landlock will always deny\nattempts to reparent files between different directories.\n\nIn addition to the source and destination directories having the LANDLOCKAC‐\nCESSFSREFER access right, the attempted link or rename operation must meet the fol‐\nlowing constraints:\n\n• The reparented file may not gain more access rights in the destination directory\nthan it previously had in the source directory. If this is attempted, the opera‐\ntion results in an EXDEV error.\n\n• When linking or renaming, the LANDLOCKACCESSFSMAKE* right for the respective\nfile type must be granted for the destination directory. Otherwise, the operation\nresults in an EACCES error.\n\n• When renaming, the LANDLOCKACCESSFSREMOVE* right for the respective file type\nmust be granted for the source directory. Otherwise, the operation results in an\nEACCES error.\n\nIf multiple requirements are not met, the EACCES error code takes precedence over\nEXDEV.\n" }, { "name": "Layers of file path access rights", "content": "Each time a thread enforces a ruleset on itself, it updates its Landlock domain with a new\nlayer of policy. Indeed, this complementary policy is composed with the potentially other\nrulesets already restricting this thread. A sandboxed thread can then safely add more con‐\nstraints to itself with a new enforced ruleset.\n\nOne policy layer grants access to a file path if at least one of its rules encountered on the\npath grants the access. A sandboxed thread can only access a file path if all its enforced\npolicy layers grant the access as well as all the other system access controls (e.g.,\nfilesystem DAC, other LSM policies, etc.).\n" }, { "name": "Bind mounts and OverlayFS", "content": "Landlock enables restricting access to file hierarchies, which means that these access rights\ncan be propagated with bind mounts (cf. mountnamespaces(7)) but not with OverlayFS.\n\nA bind mount mirrors a source file hierarchy to a destination. The destination hierarchy is\nthen composed of the exact same files, on which Landlock rules can be tied, either via the\nsource or the destination path. These rules restrict access when they are encountered on a\npath, which means that they can restrict access to multiple file hierarchies at the same\ntime, whether these hierarchies are the result of bind mounts or not.\n\nAn OverlayFS mount point consists of upper and lower layers. These layers are combined in a\nmerge directory, result of the mount point. This merge hierarchy may include files from the\nupper and lower layers, but modifications performed on the merge hierarchy only reflect on\nthe upper layer. From a Landlock policy point of view, each of the OverlayFS layers and\nmerge hierarchies is standalone and contains its own set of files and directories, which is\ndifferent from a bind mount. A policy restricting an OverlayFS layer will not restrict the\nresulted merged hierarchy, and vice versa. Landlock users should then only think about file\nhierarchies they want to allow access to, regardless of the underlying filesystem.\n" }, { "name": "Inheritance", "content": "Every new thread resulting from a clone(2) inherits Landlock domain restrictions from its\nparent. This is similar to the seccomp(2) inheritance or any other LSM dealing with tasks'\ncredentials(7). For instance, one process's thread may apply Landlock rules to itself, but\nthey will not be automatically applied to other sibling threads (unlike POSIX thread creden‐\ntial changes, cf. nptl(7)).\n\nWhen a thread sandboxes itself, we have the guarantee that the related security policy will\nstay enforced on all this thread's descendants. This allows creating standalone and modular\nsecurity policies per application, which will automatically be composed between themselves\naccording to their run-time parent policies.\n" }, { "name": "Ptrace restrictions", "content": "A sandboxed process has less privileges than a non-sandboxed process and must then be subject\nto additional restrictions when manipulating another process. To be allowed to use ptrace(2)\nand related syscalls on a target process, a sandboxed process should have a subset of the\ntarget process rules, which means the tracee must be in a sub-domain of the tracer.\n" }, { "name": "Truncating files", "content": "The operations covered by LANDLOCKACCESSFSWRITEFILE and LANDLOCKACCESSFSTRUNCATE both\nchange the contents of a file and sometimes overlap in non-intuitive ways. It is recommended\nto always specify both of these together.\n\nA particularly surprising example is creat(2). The name suggests that this system call re‐\nquires the rights to create and write files. However, it also requires the truncate right if\nan existing file under the same name is already present.\n\nIt should also be noted that truncating files does not require the LANDLOCKAC‐\nCESSFSWRITEFILE right. Apart from the truncate(2) system call, this can also be done\nthrough open(2) with the flags ORDONLY | OTRUNC.\n\nWhen opening a file, the availability of the LANDLOCKACCESSFSTRUNCATE right is associated\nwith the newly created file descriptor and will be used for subsequent truncation attempts\nusing ftruncate(2). The behavior is similar to opening a file for reading or writing, where\npermissions are checked during open(2), but not during the subsequent read(2) and write(2)\ncalls.\n\nAs a consequence, it is possible to have multiple open file descriptors for the same file,\nwhere one grants the right to truncate the file and the other does not. It is also possible\nto pass such file descriptors between processes, keeping their Landlock properties, even when\nthese processes do not have an enforced Landlock ruleset.\n" } ] }, "VERSIONS": { "content": "Landlock was introduced in Linux 5.13.\n\nTo determine which Landlock features are available, users should query the Landlock ABI ver‐\nsion:\n┌─────┬────────┬────────────────────────────────────────────────────────────────────────────┐\n│ ABI │ Kernel │ Newly introduced access rights │\n├─────┼────────┼────────────────────────────────────────────────────────────────────────────┤\n│ 1 │ 5.13 │ LANDLOCKACCESSFSEXECUTE │\n│ │ │ LANDLOCKACCESSFSWRITEFILE │\n│ │ │ LANDLOCKACCESSFSREADFILE │\n│ │ │ LANDLOCKACCESSFSREADDIR │\n│ │ │ LANDLOCKACCESSFSREMOVEDIR │\n│ │ │ LANDLOCKACCESSFSREMOVEFILE │\n│ │ │ LANDLOCKACCESSFSMAKECHAR │\n│ │ │ LANDLOCKACCESSFSMAKEDIR │\n│ │ │ LANDLOCKACCESSFSMAKEREG │\n│ │ │ LANDLOCKACCESSFSMAKESOCK │\n│ │ │ LANDLOCKACCESSFSMAKEFIFO │\n│ │ │ LANDLOCKACCESSFSMAKEBLOCK │\n│ │ │ LANDLOCKACCESSFSMAKESYM │\n├─────┼────────┼────────────────────────────────────────────────────────────────────────────┤\n│ 2 │ 5.19 │ LANDLOCKACCESSFSREFER │\n├─────┼────────┼────────────────────────────────────────────────────────────────────────────┤\n│ 3 │ 6.2 │ LANDLOCKACCESSFSTRUNCATE │\n└─────┴────────┴────────────────────────────────────────────────────────────────────────────┘\n\nUsers should use the Landlock ABI version rather than the kernel version to determine which\nfeatures are available. The mainline kernel versions listed here are only included for ori‐\nentation. Kernels from other sources may contain backported features, and their version num‐\nbers may not match.\n\nTo query the running kernel's Landlock ABI version, programs may pass the LANDLOCKCRE‐\nATERULESETVERSION flag to landlockcreateruleset(2).\n\nWhen building fallback mechanisms for compatibility with older kernels, users are advised to\nconsider the special semantics of the LANDLOCKACCESSFSREFER access right: In ABI v1, link‐\ning and moving of files between different directories is always forbidden, so programs rely‐\ning on such operations are only compatible with Landlock ABI v2 and higher.\n", "subsections": [] }, "NOTES": { "content": "Landlock is enabled by CONFIGSECURITYLANDLOCK. The lsm=lsm1,...,lsmN command line parame‐\nter controls the sequence of the initialization of Linux Security Modules. It must contain\nthe string landlock to enable Landlock. If the command line parameter is not specified, the\ninitialization falls back to the value of the deprecated security= command line parameter and\nfurther to the value of CONFIGLSM. We can check that Landlock is enabled by looking for\nlandlock: Up and running. in kernel logs.\n", "subsections": [] }, "CAVEATS": { "content": "It is currently not possible to restrict some file-related actions accessible through these\nsystem call families: chdir(2), stat(2), flock(2), chmod(2), chown(2), setxattr(2), utime(2),\nioctl(2), fcntl(2), access(2). Future Landlock evolutions will enable to restrict them.\n", "subsections": [] }, "EXAMPLES": { "content": "We first need to create the ruleset that will contain our rules.\n\nFor this example, the ruleset will contain rules that only allow read actions, but write ac‐\ntions will be denied. The ruleset then needs to handle both of these kinds of actions. See\nthe DESCRIPTION section for the description of filesystem actions.\n\nstruct landlockrulesetattr attr = {0};\nint rulesetfd;\n\nattr.handledaccessfs =\nLANDLOCKACCESSFSEXECUTE |\nLANDLOCKACCESSFSWRITEFILE |\nLANDLOCKACCESSFSREADFILE |\nLANDLOCKACCESSFSREADDIR |\nLANDLOCKACCESSFSREMOVEDIR |\nLANDLOCKACCESSFSREMOVEFILE |\nLANDLOCKACCESSFSMAKECHAR |\nLANDLOCKACCESSFSMAKEDIR |\nLANDLOCKACCESSFSMAKEREG |\nLANDLOCKACCESSFSMAKESOCK |\nLANDLOCKACCESSFSMAKEFIFO |\nLANDLOCKACCESSFSMAKEBLOCK |\nLANDLOCKACCESSFSMAKESYM |\nLANDLOCKACCESSFSREFER |\nLANDLOCKACCESSFSTRUNCATE;\n\nTo be compatible with older Linux versions, we detect the available Landlock ABI version, and\nonly use the available subset of access rights:\n\n/*\n* Table of available file system access rights by ABI version,\n* numbers hardcoded to keep the example short.\n*/\nu64 landlockfsaccessrights[] = {\n(LANDLOCKACCESSFSMAKESYM << 1) - 1, /* v1 */\n(LANDLOCKACCESSFSREFER << 1) - 1, /* v2: add \"refer\" */\n(LANDLOCKACCESSFSTRUNCATE << 1) - 1, /* v3: add \"truncate\" */\n};\n\nint abi = landlockcreateruleset(NULL, 0,\nLANDLOCKCREATERULESETVERSION);\nif (abi == -1) {\n/*\n* Kernel too old, not compiled with Landlock,\n* or Landlock was not enabled at boot time.\n*/\nperror(\"Unable to use Landlock\");\nreturn; /* Graceful fallback: Do nothing. */\n}\nabi = MIN(abi, 3);\n\n/* Only use the available rights in the ruleset. */\nattr.handledaccessfs &= landlockfsaccessrights[abi - 1];\n\nThe available access rights for each ABI version are listed in the VERSIONS section.\n\nIf our program needed to create hard links or rename files between different directories\n(LANDLOCKACCESSFSREFER), we would require the following change to the backwards compati‐\nbility logic: Directory reparenting is not possible in a process restricted with Landlock ABI\nversion 1. Therefore, if the program needed to do file reparenting, and if only Landlock ABI\nversion 1 was available, we could not restrict the process.\n\nNow that the ruleset attributes are determined, we create the Landlock ruleset and acquire a\nfile descriptor as a handle to it, using landlockcreateruleset(2):\n\nrulesetfd = landlockcreateruleset(&attr, sizeof(attr), 0);\nif (rulesetfd == -1) {\nperror(\"Failed to create a ruleset\");\nexit(EXITFAILURE);\n}\n\nWe can now add a new rule to the ruleset through the ruleset's file descriptor. The re‐\nquested access rights must be a subset of the access rights which were specified in attr.han‐\ndledaccessfs at ruleset creation time.\n\nIn this example, the rule will only allow reading the file hierarchy /usr. Without another\nrule, write actions would then be denied by the ruleset. To add /usr to the ruleset, we open\nit with the OPATH flag and fill the struct landlockpathbeneathattr with this file de‐\nscriptor.\n\nstruct landlockpathbeneathattr pathbeneath = {0};\nint err;\n\npathbeneath.allowedaccess =\nLANDLOCKACCESSFSEXECUTE |\nLANDLOCKACCESSFSREADFILE |\nLANDLOCKACCESSFSREADDIR;\n\npathbeneath.parentfd = open(\"/usr\", OPATH | OCLOEXEC);\nif (pathbeneath.parentfd == -1) {\nperror(\"Failed to open file\");\nclose(rulesetfd);\nexit(EXITFAILURE);\n}\nerr = landlockaddrule(rulesetfd, LANDLOCKRULEPATHBENEATH,\n&pathbeneath, 0);\nclose(pathbeneath.parentfd);\nif (err) {\nperror(\"Failed to update ruleset\");\nclose(rulesetfd);\nexit(EXITFAILURE);\n}\n\nWe now have a ruleset with one rule allowing read access to /usr while denying all other han‐\ndled accesses for the filesystem. The next step is to restrict the current thread from gain‐\ning more privileges (e.g., thanks to a set-user-ID binary).\n\nif (prctl(PRSETNONEWPRIVS, 1, 0, 0, 0)) {\nperror(\"Failed to restrict privileges\");\nclose(rulesetfd);\nexit(EXITFAILURE);\n}\n\nThe current thread is now ready to sandbox itself with the ruleset.\n\nif (landlockrestrictself(rulesetfd, 0)) {\nperror(\"Failed to enforce ruleset\");\nclose(rulesetfd);\nexit(EXITFAILURE);\n}\nclose(rulesetfd);\n\nIf the landlockrestrictself(2) system call succeeds, the current thread is now restricted\nand this policy will be enforced on all its subsequently created children as well. Once a\nthread is landlocked, there is no way to remove its security policy; only adding more re‐\nstrictions is allowed. These threads are now in a new Landlock domain, merge of their parent\none (if any) with the new ruleset.\n\nFull working code can be found in https://git.kernel.org/pub/scm/linux/kernel/git/stable/\nlinux.git/tree/samples/landlock/sandboxer.c\n", "subsections": [] }, "SEE ALSO": { "content": "landlockcreateruleset(2), landlockaddrule(2), landlockrestrictself(2)\n\nhttps://landlock.io/\n\nLinux man-pages 6.7 2023-10-31 Landlock(7)", "subsections": [] } }, "summary": "Landlock - unprivileged access-control", "flags": [], "examples": [ "We first need to create the ruleset that will contain our rules.", "For this example, the ruleset will contain rules that only allow read actions, but write ac‐", "tions will be denied. The ruleset then needs to handle both of these kinds of actions. See", "the DESCRIPTION section for the description of filesystem actions.", "struct landlockrulesetattr attr = {0};", "int rulesetfd;", "attr.handledaccessfs =", "LANDLOCKACCESSFSEXECUTE |", "LANDLOCKACCESSFSWRITEFILE |", "LANDLOCKACCESSFSREADFILE |", "LANDLOCKACCESSFSREADDIR |", "LANDLOCKACCESSFSREMOVEDIR |", "LANDLOCKACCESSFSREMOVEFILE |", "LANDLOCKACCESSFSMAKECHAR |", "LANDLOCKACCESSFSMAKEDIR |", "LANDLOCKACCESSFSMAKEREG |", "LANDLOCKACCESSFSMAKESOCK |", "LANDLOCKACCESSFSMAKEFIFO |", "LANDLOCKACCESSFSMAKEBLOCK |", "LANDLOCKACCESSFSMAKESYM |", "LANDLOCKACCESSFSREFER |", "LANDLOCKACCESSFSTRUNCATE;", "To be compatible with older Linux versions, we detect the available Landlock ABI version, and", "only use the available subset of access rights:", "/*", "* Table of available file system access rights by ABI version,", "* numbers hardcoded to keep the example short.", "*/", "u64 landlockfsaccessrights[] = {", "(LANDLOCKACCESSFSMAKESYM << 1) - 1, /* v1 */", "(LANDLOCKACCESSFSREFER << 1) - 1, /* v2: add \"refer\" */", "(LANDLOCKACCESSFSTRUNCATE << 1) - 1, /* v3: add \"truncate\" */", "};", "int abi = landlockcreateruleset(NULL, 0,", "LANDLOCKCREATERULESETVERSION);", "if (abi == -1) {", "/*", "* Kernel too old, not compiled with Landlock,", "* or Landlock was not enabled at boot time.", "*/", "perror(\"Unable to use Landlock\");", "return; /* Graceful fallback: Do nothing. */", "abi = MIN(abi, 3);", "/* Only use the available rights in the ruleset. */", "attr.handledaccessfs &= landlockfsaccessrights[abi - 1];", "The available access rights for each ABI version are listed in the VERSIONS section.", "If our program needed to create hard links or rename files between different directories", "(LANDLOCKACCESSFSREFER), we would require the following change to the backwards compati‐", "bility logic: Directory reparenting is not possible in a process restricted with Landlock ABI", "version 1. Therefore, if the program needed to do file reparenting, and if only Landlock ABI", "version 1 was available, we could not restrict the process.", "Now that the ruleset attributes are determined, we create the Landlock ruleset and acquire a", "file descriptor as a handle to it, using landlockcreateruleset(2):", "rulesetfd = landlockcreateruleset(&attr, sizeof(attr), 0);", "if (rulesetfd == -1) {", "perror(\"Failed to create a ruleset\");", "exit(EXITFAILURE);", "We can now add a new rule to the ruleset through the ruleset's file descriptor. The re‐", "quested access rights must be a subset of the access rights which were specified in attr.han‐", "dledaccessfs at ruleset creation time.", "In this example, the rule will only allow reading the file hierarchy /usr. Without another", "rule, write actions would then be denied by the ruleset. To add /usr to the ruleset, we open", "it with the OPATH flag and fill the struct landlockpathbeneathattr with this file de‐", "scriptor.", "struct landlockpathbeneathattr pathbeneath = {0};", "int err;", "pathbeneath.allowedaccess =", "LANDLOCKACCESSFSEXECUTE |", "LANDLOCKACCESSFSREADFILE |", "LANDLOCKACCESSFSREADDIR;", "pathbeneath.parentfd = open(\"/usr\", OPATH | OCLOEXEC);", "if (pathbeneath.parentfd == -1) {", "perror(\"Failed to open file\");", "close(rulesetfd);", "exit(EXITFAILURE);", "err = landlockaddrule(rulesetfd, LANDLOCKRULEPATHBENEATH,", "&pathbeneath, 0);", "close(pathbeneath.parentfd);", "if (err) {", "perror(\"Failed to update ruleset\");", "close(rulesetfd);", "exit(EXITFAILURE);", "We now have a ruleset with one rule allowing read access to /usr while denying all other han‐", "dled accesses for the filesystem. The next step is to restrict the current thread from gain‐", "ing more privileges (e.g., thanks to a set-user-ID binary).", "if (prctl(PRSETNONEWPRIVS, 1, 0, 0, 0)) {", "perror(\"Failed to restrict privileges\");", "close(rulesetfd);", "exit(EXITFAILURE);", "The current thread is now ready to sandbox itself with the ruleset.", "if (landlockrestrictself(rulesetfd, 0)) {", "perror(\"Failed to enforce ruleset\");", "close(rulesetfd);", "exit(EXITFAILURE);", "close(rulesetfd);", "If the landlockrestrictself(2) system call succeeds, the current thread is now restricted", "and this policy will be enforced on all its subsequently created children as well. Once a", "thread is landlocked, there is no way to remove its security policy; only adding more re‐", "strictions is allowed. These threads are now in a new Landlock domain, merge of their parent", "one (if any) with the new ruleset.", "Full working code can be found in https://git.kernel.org/pub/scm/linux/kernel/git/stable/", "linux.git/tree/samples/landlock/sandboxer.c" ], "see_also": [ { "name": "landlockcreateruleset", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/landlockcreateruleset/2/json" }, { "name": "landlockaddrule", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/landlockaddrule/2/json" }, { "name": "landlockrestrictself", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/landlockrestrictself/2/json" } ] }