Skip to content
Snippets Groups Projects
  1. Oct 19, 2022
  2. Sep 29, 2022
  3. Sep 02, 2022
    • Mickaël Salaün's avatar
      landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER · 55e55920
      Mickaël Salaün authored
      
      This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right
      when multiple rulesets/domains are stacked. The expected behaviour was
      that an additional ruleset can only restrict the set of permitted
      operations, but in this particular case, it was potentially possible to
      re-gain the LANDLOCK_ACCESS_FS_REFER right.
      
      With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first
      globally denied-by-default access right.  Indeed, this lifted an initial
      Landlock limitation to rename and link files, which was initially always
      denied when the source or the destination were different directories.
      
      This led to an inconsistent backward compatibility behavior which was
      only taken into account if no domain layer were using the new
      LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with
      a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent
      rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would
      behave as if they were handling this access right and with all their
      rules allowing it. This means that renaming and linking files could
      became allowed by these parent layers, but all the other required
      accesses must also be granted: all layers must allow file removal or
      creation, and renaming and linking operations cannot lead to privilege
      escalation according to the Landlock policy.  See detailed explanation
      in commit b91c3e4e ("landlock: Add support for file reparenting with
      LANDLOCK_ACCESS_FS_REFER").
      
      To say it another way, this bug may lift the renaming and linking
      limitations of the initial Landlock version, and a same ruleset can
      enforce different restrictions depending on previous or next enforced
      ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right
      cannot give access to data not already allowed, but this doesn't follow
      the contract of the first Landlock ABI. This fix puts back the
      limitation for sandboxes that didn't opt-in for this additional right.
      
      For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on
      /dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to
      /dst/file is denied. However, without this fix, stacking a new ruleset
      which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the
      sandboxed thread to rename /src/file to /dst/file .
      
      This change fixes the (absolute) rule access rights, which now always
      forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed
      when creating a rule.
      
      Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial
      approach but there is two downsides:
      * it makes the code more complex because we still want to check that a
        rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the
        ruleset's handled access rights (i.e. ABI v1 != ABI v2);
      * it would not allow to identify if the user created a ruleset
        explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an
        issue to audit Landlock.
      
      Instead, this change adds an ACCESS_INITIALLY_DENIED list of
      denied-by-default rights, which (only) contains
      LANDLOCK_ACCESS_FS_REFER.  All domains are treated as if they are also
      handling this list, but without modifying their fs_access_masks field.
      
      A side effect is that the errno code returned by rename(2) or link(2)
      *may* be changed from EXDEV to EACCES according to the enforced
      restrictions.  Indeed, we now have the mechanic to identify if an access
      is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG,
      LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing
      LANDLOCK_ACCESS_FS_REFER rights.  This may result in different errno
      codes than for the initial Landlock version, but this approach is more
      consistent and better for rename/link compatibility reasons, and it
      wasn't possible before (hence no backport to ABI v1).  The
      layout1.rename_file test reflects this change.
      
      Add 4 layout1.refer_denied_by_default* test suites to check that the
      behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is
      unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e.
      ABI v1 precedence).  Make sure rule's absolute access rights are correct
      by testing with and without a matching path.  Add test_rename() and
      test_exchange() helpers.
      
      Extend layout1.inval tests to check that a denied-by-default access
      right is not necessarily part of a domain's handled access rights.
      
      Test coverage for security/landlock is 95.3% of 599 lines according to
      gcc/gcov-11.
      
      Fixes: b91c3e4e ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER")
      Reviewed-by: default avatarPaul Moore <paul@paul-moore.com>
      Reviewed-by: default avatarGünther Noack <gnoack3000@gmail.com>
      Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net
      
      
      Cc: stable@vger.kernel.org
      [mic: Constify and slightly simplify test helpers]
      Signed-off-by: default avatarMickaël Salaün <mic@digikod.net>
      55e55920
  4. May 23, 2022
  5. May 09, 2022
  6. Feb 04, 2022
  7. Apr 22, 2021
    • Mickaël Salaün's avatar
      landlock: Enable user space to infer supported features · 3532b0b4
      Mickaël Salaün authored
      
      Add a new flag LANDLOCK_CREATE_RULESET_VERSION to
      landlock_create_ruleset(2).  This enables to retreive a Landlock ABI
      version that is useful to efficiently follow a best-effort security
      approach.  Indeed, it would be a missed opportunity to abort the whole
      sandbox building, because some features are unavailable, instead of
      protecting users as much as possible with the subset of features
      provided by the running kernel.
      
      This new flag enables user space to identify the minimum set of Landlock
      features supported by the running kernel without relying on a filesystem
      interface (e.g. /proc/version, which might be inaccessible) nor testing
      multiple syscall argument combinations (i.e. syscall bisection).  New
      Landlock features will be documented and tied to a minimum version
      number (greater than 1).  The current version will be incremented for
      each new kernel release supporting new Landlock features.  User space
      libraries can leverage this information to seamlessly restrict processes
      as much as possible while being compatible with newer APIs.
      
      This is a much more lighter approach than the previous
      landlock_get_features(2): the complexity is pushed to user space
      libraries.  This flag meets similar needs as securityfs versions:
      selinux/policyvers, apparmor/features/*/version* and tomoyo/version.
      
      Supporting this flag now will be convenient for backward compatibility.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Serge E. Hallyn <serge@hallyn.com>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Link: https://lore.kernel.org/r/20210422154123.13086-14-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      3532b0b4
    • Mickaël Salaün's avatar
      landlock: Add syscall implementations · 265885da
      Mickaël Salaün authored
      
      These 3 system calls are designed to be used by unprivileged processes
      to sandbox themselves:
      * landlock_create_ruleset(2): Creates a ruleset and returns its file
        descriptor.
      * landlock_add_rule(2): Adds a rule (e.g. file hierarchy access) to a
        ruleset, identified by the dedicated file descriptor.
      * landlock_restrict_self(2): Enforces a ruleset on the calling thread
        and its future children (similar to seccomp).  This syscall has the
        same usage restrictions as seccomp(2): the caller must have the
        no_new_privs attribute set or have CAP_SYS_ADMIN in the current user
        namespace.
      
      All these syscalls have a "flags" argument (not currently used) to
      enable extensibility.
      
      Here are the motivations for these new syscalls:
      * A sandboxed process may not have access to file systems, including
        /dev, /sys or /proc, but it should still be able to add more
        restrictions to itself.
      * Neither prctl(2) nor seccomp(2) (which was used in a previous version)
        fit well with the current definition of a Landlock security policy.
      
      All passed structs (attributes) are checked at build time to ensure that
      they don't contain holes and that they are aligned the same way for each
      architecture.
      
      See the user and kernel documentation for more details (provided by a
      following commit):
      * Documentation/userspace-api/landlock.rst
      * Documentation/security/landlock.rst
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Link: https://lore.kernel.org/r/20210422154123.13086-9-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      265885da
    • Mickaël Salaün's avatar
      landlock: Support filesystem access-control · cb2c7d1a
      Mickaël Salaün authored
      
      Using Landlock objects and ruleset, it is possible to tag inodes
      according to a process's domain.  To enable an unprivileged process to
      express a file hierarchy, it first needs to open a directory (or a file)
      and pass this file descriptor to the kernel through
      landlock_add_rule(2).  When checking if a file access request is
      allowed, we walk from the requested dentry to the real root, following
      the different mount layers.  The access to each "tagged" inodes are
      collected according to their rule layer level, and ANDed to create
      access to the requested file hierarchy.  This makes possible to identify
      a lot of files without tagging every inodes nor modifying the
      filesystem, while still following the view and understanding the user
      has from the filesystem.
      
      Add a new ARCH_EPHEMERAL_INODES for UML because it currently does not
      keep the same struct inodes for the same inodes whereas these inodes are
      in use.
      
      This commit adds a minimal set of supported filesystem access-control
      which doesn't enable to restrict all file-related actions.  This is the
      result of multiple discussions to minimize the code of Landlock to ease
      review.  Thanks to the Landlock design, extending this access-control
      without breaking user space will not be a problem.  Moreover, seccomp
      filters can be used to restrict the use of syscall families which may
      not be currently handled by Landlock.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Serge E. Hallyn <serge@hallyn.com>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Link: https://lore.kernel.org/r/20210422154123.13086-8-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      cb2c7d1a
    • Mickaël Salaün's avatar
      landlock: Add ptrace restrictions · afe81f75
      Mickaël Salaün authored
      
      Using ptrace(2) and related debug features on a target process can lead
      to a privilege escalation.  Indeed, ptrace(2) can be used by an attacker
      to impersonate another task and to remain undetected while performing
      malicious activities.  Thanks to  ptrace_may_access(), various part of
      the kernel can check if a tracer is more privileged than a tracee.
      
      A landlocked process has fewer privileges than a non-landlocked process
      and must then be subject to additional restrictions when manipulating
      processes. To be allowed to use ptrace(2) and related syscalls on a
      target process, a landlocked process must have a subset of the target
      process's rules (i.e. the tracee must be in a sub-domain of the tracer).
      
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210422154123.13086-5-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      afe81f75
    • Mickaël Salaün's avatar
      landlock: Set up the security framework and manage credentials · 385975dc
      Mickaël Salaün authored
      
      Process's credentials point to a Landlock domain, which is underneath
      implemented with a ruleset.  In the following commits, this domain is
      used to check and enforce the ptrace and filesystem security policies.
      A domain is inherited from a parent to its child the same way a thread
      inherits a seccomp policy.
      
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210422154123.13086-4-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      385975dc
    • Mickaël Salaün's avatar
      landlock: Add ruleset and domain management · ae271c1b
      Mickaël Salaün authored
      
      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 syscalls) 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
      defines 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.
      
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Link: https://lore.kernel.org/r/20210422154123.13086-3-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      ae271c1b
    • Mickaël Salaün's avatar
      landlock: Add object management · 90945448
      Mickaël Salaün authored
      
      A Landlock object enables to identify a kernel object (e.g. an inode).
      A Landlock rule is a set of access rights allowed on an object.  Rules
      are grouped in rulesets that may be tied to a set of processes (i.e.
      subjects) to enforce a scoped access-control (i.e. a domain).
      
      Because Landlock's goal is to empower any process (especially
      unprivileged ones) to sandbox themselves, we cannot rely on a
      system-wide object identification such as file extended attributes.
      Indeed, we need innocuous, composable and modular access-controls.
      
      The main challenge with these constraints is to identify kernel objects
      while this identification is useful (i.e. when a security policy makes
      use of this object).  But this identification data should be freed once
      no policy is using it.  This ephemeral tagging should not and may not be
      written in the filesystem.  We then need to manage the lifetime of a
      rule according to the lifetime of its objects.  To avoid a global lock,
      this implementation make use of RCU and counters to safely reference
      objects.
      
      A following commit uses this generic object management for inodes.
      
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210422154123.13086-2-mic@digikod.net
      
      
      Signed-off-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      90945448
Loading