1Landlock(7)            Miscellaneous Information Manual            Landlock(7)
2
3
4

NAME

6       Landlock - unprivileged access-control
7

DESCRIPTION

9       Landlock  is an access-control system that enables any processes to se‐
10       curely restrict themselves and their future children.  Because Landlock
11       is  a  stackable  Linux  Security Module (LSM), it makes it possible to
12       create safe security sandboxes as new security layers  in  addition  to
13       the  existing system-wide access-controls.  This kind of sandbox is ex‐
14       pected to help mitigate the security impact of bugs, and unexpected  or
15       malicious behaviors in applications.
16
17       A Landlock security policy is a set of access rights (e.g., open a file
18       in read-only, make a directory, etc.)  tied to a file hierarchy.   Such
19       policy can be configured and enforced by processes for themselves using
20       three system calls:
21
22landlock_create_ruleset(2) creates a new ruleset;
23
24landlock_add_rule(2) adds a new rule to a ruleset;
25
26landlock_restrict_self(2) enforces a ruleset on the calling thread.
27
28       To be able to use these system calls, the running kernel  must  support
29       Landlock and it must be enabled at boot time.
30
31   Landlock rules
32       A  Landlock  rule  describes an action on an object.  An object is cur‐
33       rently a file hierarchy, and the related filesystem actions are defined
34       with  access  rights (see landlock_add_rule(2)).  A set of rules is ag‐
35       gregated in a ruleset, which can then restrict the thread enforcing it,
36       and its future children.
37
38   Filesystem actions
39       These  flags enable to restrict a sandboxed process to a set of actions
40       on files and directories.  Files or directories opened before the sand‐
41       boxing are not subject to these restrictions.  See landlock_add_rule(2)
42       and landlock_create_ruleset(2) for more context.
43
44       A file can only receive these access rights:
45
46       LANDLOCK_ACCESS_FS_EXECUTE
47              Execute a file.
48
49       LANDLOCK_ACCESS_FS_WRITE_FILE
50              Open a file with write access.
51
52              When opening files for writing, you will often additionally need
53              the  LANDLOCK_ACCESS_FS_TRUNCATE  right.   In  many cases, these
54              system calls  truncate  existing  files  when  overwriting  them
55              (e.g., creat(2)).
56
57       LANDLOCK_ACCESS_FS_READ_FILE
58              Open a file with read access.
59
60       LANDLOCK_ACCESS_FS_TRUNCATE
61              Truncate  a  file  with  truncate(2), ftruncate(2), creat(2), or
62              open(2) with O_TRUNC.  Whether an opened file can  be  truncated
63              with  ftruncate(2) is determined during open(2), in the same way
64              as read and write permissions are checked during  open(2)  using
65              LANDLOCK_ACCESS_FS_READ_FILE  and LANDLOCK_ACCESS_FS_WRITE_FILE.
66              This access right is available since the third  version  of  the
67              Landlock ABI.
68
69       A  directory can receive access rights related to files or directories.
70       The following access right is applied to the directory itself, and  the
71       directories beneath it:
72
73       LANDLOCK_ACCESS_FS_READ_DIR
74              Open a directory or list its content.
75
76       However, the following access rights only apply to the content of a di‐
77       rectory, not the directory itself:
78
79       LANDLOCK_ACCESS_FS_REMOVE_DIR
80              Remove an empty directory or rename one.
81
82       LANDLOCK_ACCESS_FS_REMOVE_FILE
83              Unlink (or rename) a file.
84
85       LANDLOCK_ACCESS_FS_MAKE_CHAR
86              Create (or rename or link) a character device.
87
88       LANDLOCK_ACCESS_FS_MAKE_DIR
89              Create (or rename) a directory.
90
91       LANDLOCK_ACCESS_FS_MAKE_REG
92              Create (or rename or link) a regular file.
93
94       LANDLOCK_ACCESS_FS_MAKE_SOCK
95              Create (or rename or link) a UNIX domain socket.
96
97       LANDLOCK_ACCESS_FS_MAKE_FIFO
98              Create (or rename or link) a named pipe.
99
100       LANDLOCK_ACCESS_FS_MAKE_BLOCK
101              Create (or rename or link) a block device.
102
103       LANDLOCK_ACCESS_FS_MAKE_SYM
104              Create (or rename or link) a symbolic link.
105
106       LANDLOCK_ACCESS_FS_REFER
107              Link or rename a file from or to a  different  directory  (i.e.,
108              reparent a file hierarchy).
109
110              This  access  right is available since the second version of the
111              Landlock ABI.
112
113              This is the only access right which is denied by default by  any
114              ruleset,  even if the right is not specified as handled at rule‐
115              set creation time.  The only way to make a  ruleset  grant  this
116              right  is  to  explicitly  allow  it for a specific directory by
117              adding a matching rule to the ruleset.
118
119              In particular, when using the first Landlock ABI version,  Land‐
120              lock will always deny attempts to reparent files between differ‐
121              ent directories.
122
123              In addition to the source and destination directories having the
124              LANDLOCK_ACCESS_FS_REFER access right, the attempted link or re‐
125              name operation must meet the following constraints:
126
127              •  The reparented file may not gain more access  rights  in  the
128                 destination  directory  than  it previously had in the source
129                 directory.  If this is attempted, the operation results in an
130                 EXDEV error.
131
132              •  When linking or renaming, the LANDLOCK_ACCESS_FS_MAKE_* right
133                 for the respective file type must be granted for the destina‐
134                 tion  directory.  Otherwise, the operation results in an EAC‐
135                 CES error.
136
137              •  When renaming, the LANDLOCK_ACCESS_FS_REMOVE_* right for  the
138                 respective  file  type  must be granted for the source direc‐
139                 tory.  Otherwise, the operation results in an EACCES error.
140
141              If multiple requirements are not  met,  the  EACCES  error  code
142              takes precedence over EXDEV.
143
144   Layers of file path access rights
145       Each  time  a thread enforces a ruleset on itself, it updates its Land‐
146       lock domain with a new layer of  policy.   Indeed,  this  complementary
147       policy  is  composed  with  the  potentially other rulesets already re‐
148       stricting this thread.  A sandboxed thread can  then  safely  add  more
149       constraints to itself with a new enforced ruleset.
150
151       One  policy  layer  grants access to a file path if at least one of its
152       rules encountered on the path grants the access.   A  sandboxed  thread
153       can only access a file path if all its enforced policy layers grant the
154       access as well as all the other system access controls (e.g.,  filesys‐
155       tem DAC, other LSM policies, etc.).
156
157   Bind mounts and OverlayFS
158       Landlock  enables  restricting  access to file hierarchies, which means
159       that these access rights  can  be  propagated  with  bind  mounts  (cf.
160       mount_namespaces(7)) but not with OverlayFS.
161
162       A  bind  mount  mirrors  a source file hierarchy to a destination.  The
163       destination hierarchy is then composed of  the  exact  same  files,  on
164       which Landlock rules can be tied, either via the source or the destina‐
165       tion path.  These rules restrict access when they are encountered on  a
166       path,  which means that they can restrict access to multiple file hier‐
167       archies at the same time, whether these hierarchies are the  result  of
168       bind mounts or not.
169
170       An  OverlayFS  mount  point  consists of upper and lower layers.  These
171       layers are combined in a merge directory, result of  the  mount  point.
172       This merge hierarchy may include files from the upper and lower layers,
173       but modifications performed on the merge hierarchy only reflect on  the
174       upper  layer.   From a Landlock policy point of view, each of the Over‐
175       layFS layers and merge hierarchies is standalone and contains  its  own
176       set  of files and directories, which is different from a bind mount.  A
177       policy restricting an OverlayFS layer will not  restrict  the  resulted
178       merged  hierarchy,  and  vice  versa.   Landlock users should then only
179       think about file hierarchies they want to allow access  to,  regardless
180       of the underlying filesystem.
181
182   Inheritance
183       Every new thread resulting from a clone(2) inherits Landlock domain re‐
184       strictions from its parent.  This is similar to the seccomp(2)  inheri‐
185       tance  or  any  other  LSM dealing with tasks' credentials(7).  For in‐
186       stance, one process's thread may apply Landlock rules  to  itself,  but
187       they will not be automatically applied to other sibling threads (unlike
188       POSIX thread credential changes, cf.  nptl(7)).
189
190       When a thread sandboxes itself, we have the guarantee that the  related
191       security  policy  will  stay enforced on all this thread's descendants.
192       This allows creating standalone and modular security policies  per  ap‐
193       plication,  which will automatically be composed between themselves ac‐
194       cording to their runtime parent policies.
195
196   Ptrace restrictions
197       A sandboxed process has less privileges than  a  non-sandboxed  process
198       and  must  then be subject to additional restrictions when manipulating
199       another process.  To be allowed to use ptrace(2) and  related  syscalls
200       on  a  target  process, a sandboxed process should have a subset of the
201       target process rules, which means the tracee must be in a sub-domain of
202       the tracer.
203
204   Truncating files
205       The  operations  covered  by  LANDLOCK_ACCESS_FS_WRITE_FILE  and  LAND‐
206       LOCK_ACCESS_FS_TRUNCATE both change the contents of a  file  and  some‐
207       times overlap in non-intuitive ways.  It is recommended to always spec‐
208       ify both of these together.
209
210       A particularly surprising example is creat(2).  The name suggests  that
211       this  system  call requires the rights to create and write files.  How‐
212       ever, it also requires the truncate right if an existing file under the
213       same name is already present.
214
215       It  should  also  be  noted  that truncating files does not require the
216       LANDLOCK_ACCESS_FS_WRITE_FILE right.  Apart from the truncate(2) system
217       call,   this   can   also  be  done  through  open(2)  with  the  flags
218       O_RDONLY | O_TRUNC.
219
220       When opening a file, the availability of  the  LANDLOCK_ACCESS_FS_TRUN‐
221       CATE  right  is  associated  with the newly created file descriptor and
222       will be used for subsequent  truncation  attempts  using  ftruncate(2).
223       The behavior is similar to opening a file for reading or writing, where
224       permissions are checked during open(2), but not during  the  subsequent
225       read(2) and write(2) calls.
226
227       As a consequence, it is possible to have multiple open file descriptors
228       for the same file, where one grants the right to truncate the file  and
229       the  other does not.  It is also possible to pass such file descriptors
230       between processes, keeping their Landlock properties, even  when  these
231       processes do not have an enforced Landlock ruleset.
232

VERSIONS

234       Landlock was introduced in Linux 5.13.
235
236       To  determine which Landlock features are available, users should query
237       the Landlock ABI version:
238
239       ┌────┬────────┬────────────────────────────────────────────────────────┐
240ABI Kernel Newly introduced access rights                         
241       ├────┼────────┼────────────────────────────────────────────────────────┤
242       │ 1  │  5.13  │ LANDLOCK_ACCESS_FS_EXECUTE                             
243       │    │        │ LANDLOCK_ACCESS_FS_WRITE_FILE                          
244       │    │        │ LANDLOCK_ACCESS_FS_READ_FILE                           
245       │    │        │ LANDLOCK_ACCESS_FS_READ_DIR                            
246       │    │        │ LANDLOCK_ACCESS_FS_REMOVE_DIR                          
247       │    │        │ LANDLOCK_ACCESS_FS_REMOVE_FILE                         
248       │    │        │ LANDLOCK_ACCESS_FS_MAKE_CHAR                           
249       │    │        │ LANDLOCK_ACCESS_FS_MAKE_DIR                            
250       │    │        │ LANDLOCK_ACCESS_FS_MAKE_REG                            
251       │    │        │ LANDLOCK_ACCESS_FS_MAKE_SOCK                           
252       │    │        │ LANDLOCK_ACCESS_FS_MAKE_FIFO                           
253       │    │        │ LANDLOCK_ACCESS_FS_MAKE_BLOCK                          
254       │    │        │ LANDLOCK_ACCESS_FS_MAKE_SYM                            
255       ├────┼────────┼────────────────────────────────────────────────────────┤
256       │ 2  │  5.19  │ LANDLOCK_ACCESS_FS_REFER                               
257       ├────┼────────┼────────────────────────────────────────────────────────┤
258       │ 3  │  6.2   │ LANDLOCK_ACCESS_FS_TRUNCATE                            
259       └────┴────────┴────────────────────────────────────────────────────────┘
260
261       Users should use the Landlock ABI version rather than the  kernel  ver‐
262       sion  to  determine  which features are available.  The mainline kernel
263       versions listed here are only included for orientation.   Kernels  from
264       other  sources  may contain backported features, and their version num‐
265       bers may not match.
266
267       To query the running kernel's Landlock ABI version, programs  may  pass
268       the LANDLOCK_CREATE_RULESET_VERSION flag to landlock_create_ruleset(2).
269
270       When building fallback mechanisms for compatibility with older kernels,
271       users are advised to consider the special semantics of the LANDLOCK_AC‐
272       CESS_FS_REFER  access right: In ABI v1, linking and moving of files be‐
273       tween different directories is always forbidden, so programs relying on
274       such operations are only compatible with Landlock ABI v2 and higher.
275

NOTES

277       Landlock is enabled by CONFIG_SECURITY_LANDLOCK.  The lsm=lsm1,...,lsmN
278       command line parameter controls the sequence of the  initialization  of
279       Linux  Security Modules.  It must contain the string landlock to enable
280       Landlock.  If the command line parameter is not specified, the initial‐
281       ization  falls  back  to  the value of the deprecated security= command
282       line parameter and further to the value of CONFIG_LSM.   We  can  check
283       that  Landlock  is enabled by looking for landlock: Up and running.  in
284       kernel logs.
285

CAVEATS

287       It is currently not possible to restrict some file-related actions  ac‐
288       cessible   through  these  system  call  families:  chdir(2),  stat(2),
289       flock(2), chmod(2),  chown(2),  setxattr(2),  utime(2),  ioctl(2),  fc‐
290       ntl(2),  access(2).  Future Landlock evolutions will enable to restrict
291       them.
292

EXAMPLES

294       We first need to create the ruleset that will contain our  rules.   For
295       this  example,  the ruleset will contain rules that only allow read ac‐
296       tions, but write actions will be denied.  The  ruleset  then  needs  to
297       handle  both  of these kinds of actions.  See below for the description
298       of filesystem actions.
299
300           struct landlock_ruleset_attr attr = {0};
301           int ruleset_fd;
302
303           attr.handled_access_fs =
304                   LANDLOCK_ACCESS_FS_EXECUTE |
305                   LANDLOCK_ACCESS_FS_WRITE_FILE |
306                   LANDLOCK_ACCESS_FS_READ_FILE |
307                   LANDLOCK_ACCESS_FS_READ_DIR |
308                   LANDLOCK_ACCESS_FS_REMOVE_DIR |
309                   LANDLOCK_ACCESS_FS_REMOVE_FILE |
310                   LANDLOCK_ACCESS_FS_MAKE_CHAR |
311                   LANDLOCK_ACCESS_FS_MAKE_DIR |
312                   LANDLOCK_ACCESS_FS_MAKE_REG |
313                   LANDLOCK_ACCESS_FS_MAKE_SOCK |
314                   LANDLOCK_ACCESS_FS_MAKE_FIFO |
315                   LANDLOCK_ACCESS_FS_MAKE_BLOCK |
316                   LANDLOCK_ACCESS_FS_MAKE_SYM |
317                   LANDLOCK_ACCESS_FS_REFER |
318                   LANDLOCK_ACCESS_FS_TRUNCATE;
319
320           ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
321           if (ruleset_fd == -1) {
322               perror("Failed to create a ruleset");
323               exit(EXIT_FAILURE);
324           }
325
326       We can now add a new rule to this ruleset thanks to the  returned  file
327       descriptor referring to this ruleset.  The rule will only allow reading
328       the file hierarchy /usr.  Without another  rule,  write  actions  would
329       then  be denied by the ruleset.  To add /usr to the ruleset, we open it
330       with the O_PATH flag and  fill  the  struct  landlock_path_beneath_attr
331       with this file descriptor.
332
333           struct landlock_path_beneath_attr path_beneath = {0};
334           int err;
335
336           path_beneath.allowed_access =
337                   LANDLOCK_ACCESS_FS_EXECUTE |
338                   LANDLOCK_ACCESS_FS_READ_FILE |
339                   LANDLOCK_ACCESS_FS_READ_DIR;
340
341           path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
342           if (path_beneath.parent_fd == -1) {
343               perror("Failed to open file");
344               close(ruleset_fd);
345               exit(EXIT_FAILURE);
346           }
347           err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
348                                   &path_beneath, 0);
349           close(path_beneath.parent_fd);
350           if (err) {
351               perror("Failed to update ruleset");
352               close(ruleset_fd);
353               exit(EXIT_FAILURE);
354           }
355
356       We  now have a ruleset with one rule allowing read access to /usr while
357       denying all other handled accesses for the filesystem.  The  next  step
358       is  to  restrict the current thread from gaining more privileges (e.g.,
359       thanks to a set-user-ID binary).
360
361           if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
362               perror("Failed to restrict privileges");
363               close(ruleset_fd);
364               exit(EXIT_FAILURE);
365           }
366
367       The current thread is now ready to sandbox itself with the ruleset.
368
369           if (landlock_restrict_self(ruleset_fd, 0)) {
370               perror("Failed to enforce ruleset");
371               close(ruleset_fd);
372               exit(EXIT_FAILURE);
373           }
374           close(ruleset_fd);
375
376       If the landlock_restrict_self(2)  system  call  succeeds,  the  current
377       thread  is  now  restricted and this policy will be enforced on all its
378       subsequently created children as well.  Once a  thread  is  landlocked,
379       there  is  no  way  to remove its security policy; only adding more re‐
380       strictions is allowed.  These threads are now in a new Landlock domain,
381       merge of their parent one (if any) with the new ruleset.
382
383       Full  working  code  can  be  found in ⟨https://git.kernel.org/pub/scm/
384       linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c⟩
385

SEE ALSO

387       landlock_create_ruleset(2),     landlock_add_rule(2),      landlock_re‐
388       strict_self(2)
389
390https://landlock.io/
391
392
393
394Linux man-pages 6.04              2023-04-02                       Landlock(7)
Impressum