Skip to content

Commit 5526b45

Browse files
l0kodJames Morris
authored andcommitted
landlock: Add user and kernel documentation
Add a first document describing userspace API: how to define and enforce a Landlock security policy. This is explained with a simple example. The Landlock system calls are described with their expected behavior and current limitations. Another document is dedicated to kernel developers, describing guiding principles and some important kernel structures. This documentation can be built with the Sphinx framework. Cc: James Morris <[email protected]> Cc: Jann Horn <[email protected]> Cc: Serge E. Hallyn <[email protected]> Signed-off-by: Mickaël Salaün <[email protected]> Reviewed-by: Vincent Dagonneau <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: James Morris <[email protected]>
1 parent ba84b0b commit 5526b45

File tree

5 files changed

+400
-0
lines changed

5 files changed

+400
-0
lines changed

Documentation/security/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,3 +16,4 @@ Security Documentation
1616
siphash
1717
tpm/index
1818
digsig
19+
landlock

Documentation/security/landlock.rst

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
.. Copyright © 2017-2020 Mickaël Salaün <[email protected]>
3+
.. Copyright © 2019-2020 ANSSI
4+
5+
==================================
6+
Landlock LSM: kernel documentation
7+
==================================
8+
9+
:Author: Mickaël Salaün
10+
:Date: March 2021
11+
12+
Landlock's goal is to create scoped access-control (i.e. sandboxing). To
13+
harden a whole system, this feature should be available to any process,
14+
including unprivileged ones. Because such process may be compromised or
15+
backdoored (i.e. untrusted), Landlock's features must be safe to use from the
16+
kernel and other processes point of view. Landlock's interface must therefore
17+
expose a minimal attack surface.
18+
19+
Landlock is designed to be usable by unprivileged processes while following the
20+
system security policy enforced by other access control mechanisms (e.g. DAC,
21+
LSM). Indeed, a Landlock rule shall not interfere with other access-controls
22+
enforced on the system, only add more restrictions.
23+
24+
Any user can enforce Landlock rulesets on their processes. They are merged and
25+
evaluated according to the inherited ones in a way that ensures that only more
26+
constraints can be added.
27+
28+
User space documentation can be found here: :doc:`/userspace-api/landlock`.
29+
30+
Guiding principles for safe access controls
31+
===========================================
32+
33+
* A Landlock rule shall be focused on access control on kernel objects instead
34+
of syscall filtering (i.e. syscall arguments), which is the purpose of
35+
seccomp-bpf.
36+
* To avoid multiple kinds of side-channel attacks (e.g. leak of security
37+
policies, CPU-based attacks), Landlock rules shall not be able to
38+
programmatically communicate with user space.
39+
* Kernel access check shall not slow down access request from unsandboxed
40+
processes.
41+
* Computation related to Landlock operations (e.g. enforcing a ruleset) shall
42+
only impact the processes requesting them.
43+
44+
Tests
45+
=====
46+
47+
Userspace tests for backward compatibility, ptrace restrictions and filesystem
48+
support can be found here: `tools/testing/selftests/landlock/`_.
49+
50+
Kernel structures
51+
=================
52+
53+
Object
54+
------
55+
56+
.. kernel-doc:: security/landlock/object.h
57+
:identifiers:
58+
59+
Filesystem
60+
----------
61+
62+
.. kernel-doc:: security/landlock/fs.h
63+
:identifiers:
64+
65+
Ruleset and domain
66+
------------------
67+
68+
A domain is a read-only ruleset tied to a set of subjects (i.e. tasks'
69+
credentials). Each time a ruleset is enforced on a task, the current domain is
70+
duplicated and the ruleset is imported as a new layer of rules in the new
71+
domain. Indeed, once in a domain, each rule is tied to a layer level. To
72+
grant access to an object, at least one rule of each layer must allow the
73+
requested action on the object. A task can then only transit to a new domain
74+
that is the intersection of the constraints from the current domain and those
75+
of a ruleset provided by the task.
76+
77+
The definition of a subject is implicit for a task sandboxing itself, which
78+
makes the reasoning much easier and helps avoid pitfalls.
79+
80+
.. kernel-doc:: security/landlock/ruleset.h
81+
:identifiers:
82+
83+
.. Links
84+
.. _tools/testing/selftests/landlock/:
85+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/

Documentation/userspace-api/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,7 @@ place where this information is gathered.
1818

1919
no_new_privs
2020
seccomp_filter
21+
landlock
2122
unshare
2223
spec_ctrl
2324
accelerators/ocxl

0 commit comments

Comments
 (0)