Skip to content

Commit 17ae69a

Browse files
committed
Merge tag 'landlock_v34' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull Landlock LSM from James Morris: "Add Landlock, a new LSM from Mickaël Salaün. Briefly, Landlock provides for unprivileged application sandboxing. From Mickaël's cover letter: "The goal of Landlock is to enable to restrict ambient rights (e.g. global filesystem access) for a set of processes. Because Landlock is a stackable LSM [1], it makes possible to create safe security sandboxes as new security layers in addition to the existing system-wide access-controls. This kind of sandbox is expected to help mitigate the security impact of bugs or unexpected/malicious behaviors in user-space applications. Landlock empowers any process, including unprivileged ones, to securely restrict themselves. Landlock is inspired by seccomp-bpf but instead of filtering syscalls and their raw arguments, a Landlock rule can restrict the use of kernel objects like file hierarchies, according to the kernel semantic. Landlock also takes inspiration from other OS sandbox mechanisms: XNU Sandbox, FreeBSD Capsicum or OpenBSD Pledge/Unveil. In this current form, Landlock misses some access-control features. This enables to minimize this patch series and ease review. This series still addresses multiple use cases, especially with the combined use of seccomp-bpf: applications with built-in sandboxing, init systems, security sandbox tools and security-oriented APIs [2]" The cover letter and v34 posting is here: https://lore.kernel.org/linux-security-module/[email protected]/ See also: https://landlock.io/ This code has had extensive design discussion and review over several years" Link: https://lore.kernel.org/lkml/[email protected]/ [1] Link: https://lore.kernel.org/lkml/[email protected]/ [2] * tag 'landlock_v34' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: landlock: Enable user space to infer supported features landlock: Add user and kernel documentation samples/landlock: Add a sandbox manager example selftests/landlock: Add user space tests landlock: Add syscall implementations arch: Wire up Landlock syscalls fs,security: Add sb_delete hook landlock: Support filesystem access-control LSM: Infrastructure management of the superblock landlock: Add ptrace restrictions landlock: Set up the security framework and manage credentials landlock: Add ruleset and domain management landlock: Add object management
2 parents e6f0bf0 + 3532b0b commit 17ae69a

File tree

72 files changed

+6987
-77
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

72 files changed

+6987
-77
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)