cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

landlock.rst (3856B)


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