Re: [PATCH v17 02/10] landlock: Add ruleset and domain management
On 14/05/2020 05:09, James Morris wrote: > On Mon, 11 May 2020, Mickaël Salaün wrote: > >> + * .. warning:: >> + * >> + * It is currently not possible to restrict some file-related actions >> + * accessible through these syscall families: :manpage:`chdir(2)`, >> + * :manpage:`truncate(2)`, :manpage:`stat(2)`, :manpage:`flock(2)`, >> + * :manpage:`chmod(2)`, :manpage:`chown(2)`, :manpage:`setxattr(2)`, >> + * :manpage:`ioctl(2)`, :manpage:`fcntl(2)`. >> + * Future Landlock evolutions will enable to restrict them. > > I have to wonder how useful Landlock will be without more coverage per > the above. This is the result of previous discussions (on mailing lists and conferences) to minimize the code of Landlock to ease review. There is also network and other subsystems which are not covered, the same way other LSMs may not cover everything. However, Landlock is designed to be extensible without breaking user space, so extending this access-control will not be a problem. Previous versions of this patch series handled much more. Moreover, we can compare the current situation with seccomp. Indeed, seccomp only enables to restrict system calls according to their number and their raw arguments. seccomp is designed to limit the attack surface of the kernel but it is also used to remove ways to access kernel resources. Application developers willing to sandbox their products are already using seccomp but there is limitations (e.g. file access control). Landlock addresses such limitations, which improves the current situation. We can also view seccomp as a complementary solution to the current limitations of Landlock. Indeed, seccomp filters can block or restrict the use of syscall families which may not be currently handled by Landlock. > > It would be helpful if you could outline a threat model for this initial > version, so people can get an idea of what kind of useful protection may > be gained from it. The main threat model may be seen as protecting from vulnerable (i.e. malicious) code. But because Landlock policies are defined by application developers, they also define their own threat model. > > Are there any distros or other major users who are planning on enabling or > at least investigating Landlock? I think the question should be: is there any distros which are not interested to improve the security of their users? :) Landlock is mainly designed for application developers, and most Linux distros rely on applications which are not developed by themselves. Some hardened distros such as CLIP OS and Chrome OS are interested to extend the security of the whole system with tailored sandboxing (e.g. internal and critical services, security brokers). For example, Chrome OS folks investigated with a previous version of Landlock: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel-next/+/658517/ I'm sure there is other tailored distros which will be interested once Landlock will be upstream (e.g. Tails, Qubes OS, Subgraph OS, etc.). > > Do you have any examples of a practical application of this scheme? We can start with applications with builtin sandboxing, like web browsers, web services, email services, SSH, etc. There is also all system services handled by an init system which provides security features (e.g. systemd). There is also the security sandbox tools (e.g. Minijail [1], Firejail [2], nsjail [3], Flatpak [4], etc.). And finally, security-oriented APIs such as Sandboxed API [5]. Most of them should welcome new Linux sandboxing features provided by Landlock. [1] https://android.googlesource.com/platform/external/minijail [2] https://firejail.wordpress.com/ [3] https://nsjail.dev/ [4] https://flatpak.org/ [5] https://github.com/google/sandboxed-api
Re: [PATCH v17 02/10] landlock: Add ruleset and domain management
On Mon, 11 May 2020, Mickaël Salaün wrote: > + * .. warning:: > + * > + * It is currently not possible to restrict some file-related actions > + * accessible through these syscall families: :manpage:`chdir(2)`, > + * :manpage:`truncate(2)`, :manpage:`stat(2)`, :manpage:`flock(2)`, > + * :manpage:`chmod(2)`, :manpage:`chown(2)`, :manpage:`setxattr(2)`, > + * :manpage:`ioctl(2)`, :manpage:`fcntl(2)`. > + * Future Landlock evolutions will enable to restrict them. I have to wonder how useful Landlock will be without more coverage per the above. It would be helpful if you could outline a threat model for this initial version, so people can get an idea of what kind of useful protection may be gained from it. Are there any distros or other major users who are planning on enabling or at least investigating Landlock? Do you have any examples of a practical application of this scheme? -- James Morris
[PATCH v17 02/10] landlock: Add ruleset and domain management
A Landlock ruleset is mainly a red-black tree with Landlock rules as
nodes. This enables quick update and lookup to match a requested access
e.g., to a file. A ruleset is usable through a dedicated file
descriptor (cf. following commit implementing the syscall) which enables
a process to create and populate a ruleset with new rules.
A domain is a ruleset tied to a set of processes. This group of rules
define the security policy enforced on these processes and their future
children. A domain can transition to a new domain which is the
intersection of all its constraints and those of a ruleset provided by
the current process. This modification only impact the current process.
This means that a process can only gain more constraints (i.e. lose
accesses) over time.
Signed-off-by: Mickaël Salaün
Cc: James Morris
Cc: Jann Horn
Cc: Kees Cook
Cc: Serge E. Hallyn
---
Changes since v16:
* Allow enforcement of empty ruleset, which enables deny-all policies.
Changes since v15:
* Replace layer_levels and layer_depth with a bitfield of layers, cf.
filesystem commit.
* Rename the LANDLOCK_ACCESS_FS_{UNLINK,RMDIR} with
LANDLOCK_ACCESS_FS_REMOVE_{FILE,DIR} because it makes sense to use
them for the action of renaming a file or a directory, which may lead
to the removal of the source file or directory. Removes the
LANDLOCK_ACCESS_FS_{LINK_TO,RENAME_FROM,RENAME_TO} which are now
replaced with LANDLOCK_ACCESS_FS_REMOVE_{FILE,DIR} and
LANDLOCK_ACCESS_FS_MAKE_* .
* Update the documentation accordingly and highlight how the access
rights are taken into account.
* Change nb_rules from atomic_t to u32 because it is not use anymore by
show_fdinfo().
* Add safeguard for level variables types.
* Check max number of rules.
* Replace struct landlock_access (self and beneath bitfields) with one
bitfield.
* Remove useless variable.
* Add comments.
Changes since v14:
* Simplify the object, rule and ruleset management at the expense of a
less aggressive memory freeing (contributed by Jann Horn, with
additional modifications):
- Make a domain immutable (remove the opportunistic cleaning).
- Remove RCU pointers.
- Merge struct landlock_ref and struct landlock_ruleset_elem into
landlock_rule: get ride of rule's RCU.
- Adjust union.
- Remove the landlock_insert_rule() check about a new object with the
same address as a previously disabled one, because it is not
possible to disable a rule anymore.
Cf.
https://lore.kernel.org/lkml/cag48ez21ben0wl1bbmtiiu8j9jp5iewthowz4turuj+ki0y...@mail.gmail.com/
* Fix nested domains by implementing a notion of layer level and depth:
- Update landlock_insert_rule() to manage such layers.
- Add an inherit_ruleset() helper to properly create a new domain.
- Rename landlock_find_access() to landlock_find_rule() and return a
full rule reference.
- Add a layer_level and a layer_depth fields to struct landlock_rule.
- Add a top_layer_level field to struct landlock_ruleset.
* Remove access rights that may be required for FD-only requests:
truncate, getattr, lock, chmod, chown, chgrp, ioctl. This will be
handle in a future evolution of Landlock, but right now the goal is to
lighten the code to ease review.
* Remove LANDLOCK_ACCESS_FS_OPEN and rename
LANDLOCK_ACCESS_FS_{READ,WRITE} with a FILE suffix.
* Rename LANDLOCK_ACCESS_FS_READDIR to match the *_FILE pattern.
* Remove LANDLOCK_ACCESS_FS_MAP which was useless.
* Fix memory leak in put_hierarchy() (reported by Jann Horn).
* Fix user-after-free and rename free_ruleset() (reported by Jann Horn).
* Replace the for loops with rbtree_postorder_for_each_entry_safe().
* Constify variables.
* Only use refcount_inc() through getter helpers.
* Change Landlock_insert_ruleset_access() to
Landlock_insert_ruleset_rule().
* Rename landlock_put_ruleset_enqueue() to landlock_put_ruleset_deferred().
* Improve kernel documentation and add a warning about the unhandled
access/syscall families.
* Move ABI check to syscall.c .
Changes since v13:
* New implementation, inspired by the previous inode eBPF map, but
agnostic to the underlying kernel object.
Previous changes:
https://lore.kernel.org/lkml/20190721213116.23476-7-...@digikod.net/
---
MAINTAINERS | 1 +
include/uapi/linux/landlock.h | 78
security/landlock/Makefile| 2 +-
security/landlock/ruleset.c | 342 ++
security/landlock/ruleset.h | 161
5 files changed, 583 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/linux/landlock.h
create mode 100644 security/landlock/ruleset.c
create mode 100644 security/landlock/ruleset.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 011349c9c6c6..3de0e01de0c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9493,6 +9493,7 @@ L:linux-security-mod...@vger.kernel.org
S: Supported
W: https://landlock.io
T: git https://github.com/landlock-lsm/linux.git
+F:
