From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761663AbcINHbs (ORCPT ); Wed, 14 Sep 2016 03:31:48 -0400 Received: from smtp-sh.infomaniak.ch ([128.65.195.4]:60679 "EHLO smtp-sh.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760158AbcINHZx (ORCPT ); Wed, 14 Sep 2016 03:25:53 -0400 From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= To: linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org Subject: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing Date: Wed, 14 Sep 2016 09:23:53 +0200 Message-Id: <20160914072415.26021-1-mic@digikod.net> X-Mailer: git-send-email 2.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, This series, improvement of the previous RFC [1], is a proof of concept to fill some missing part of seccomp as the ability to check syscall argument pointers or creating more dynamic security policies. The goal of this new stackable Linux Security Module (LSM) called Landlock is to allow any process, including unprivileged ones, to create powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of bugs or unexpected/malicious behaviors in userland applications. # Landlock LSM This series is mainly focused on cgroups while keeping the possibility to enforce access rules through seccomp. eBPF programs are used to create a security rule. They are very limited (i.e. can only call a whitelist of functions) and can not do a denial of service (i.e. no loop). A new dedicated eBPF map allows to collect and compare Landlock handles with system resources (e.g. files or network connections). The approach taken is to add the minimum amount of code while still allowing the userland to create quite complex access rules. A dedicated security policy language such as used by SELinux, AppArmor and other major LSMs is a lot of code and dedicated to a trusted process (i.e. root/administrator). # eBPF To get an expressive language while still being safe and small, Landlock is based on eBPF. Landlock should be usable by untrusted processes and must then expose a minimal attack surface. The eBPF bytecode is minimal while powerful, widely used and thought to be used by not so trusted application. Reusing this code allows to not reproduce the same mistakes and minimize new code while still taking a generic approach. There is only some new features like a new kind of arraymap and few dedicated eBPF functions. An eBPF program have access to an eBPF context which contains the LSM hook arguments (as does seccomp-bpf with syscall arguments). They can be used directly or passed to helper functions according to their types. It is then possible to do complex access checks without race conditions nor inconsistent evaluation (i.e. incorrect mirroring of the OS code and state [2]). There is one eBPF program subtype per LSM hook. This allow to statically check which context access is performed by an eBPF program. This is needed to deny kernel address leak and ensure the right use of LSM hook arguments with eBPF functions. Moreover, this safe pointer handling remove the need for runtime check or abstract data, which improve performances. Any user can add multiple Landlock eBPF programs per LSM hook. They are stacked and evaluated one after the other (cf. seccomp-bpf). # LSM hooks Contrary to syscalls, LSM hooks are security checkpoints and are not architecture dependant. They are designed to match a security need reflected by a security policy (e.g. access to a file). Exposing parts of some LSM hooks instead of using the syscall API for sandboxing should help to avoid bugs and hacks as encountered by the first RFC. Instead of redoing the work of the LSM hooks through syscalls, we should use and expose them as does policies of access control LSM. Only a subset of the hooks are meaningful for an unprivileged sandbox mechanism (e.g. file system or network access control). Landlock use an abstraction of raw LSM hooks, which allow to deal with possible future API changes of the LSM hook API. Moreover, thanks to the ePBF program typing (per LSM hook) used by Landlock, it should not be hard to make such evolutions backward compatible. # Use case scenario First, a process need to create a new dedicated eBPF map containing handles. This handles are references to system resources (e.g. file or directory) and grouped in one or multiple maps to be efficiently managed and checked in batches. This kind of map can be passed to Landlock eBPF functions to compare, for example, with a file access request. The handles are only accessible from the eBPF programs created by the same thread. The loaded Landlock eBPF programs can be triggered by a seccomp filter returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from a seccomp filter to eBPF programs. This allow flexible security policies between seccomp and Landlock. Another way to enforce a Landlock security policy is to attach Landlock programs to a dedicated cgroup. All the processes in this cgroup will then be subject to this policy. For unprivileged processes, this can be done thanks to cgroup delegation. A triggered Landlock eBPF program can allows or deny an access, according to its subtype (i.e. LSM hook), thanks to errno return values. # Sandbox example with process hierarchy sandboxing (seccomp) $ ls /home user1 $ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox /bin/sh -i Launching a new sandboxed process. $ ls /home ls: cannot open directory '/home': Permission denied # Sandbox example with conditional access control depending on a cgroup $ mkdir /sys/fs/cgroup/sandboxed $ ls /home user1 $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox Ready to sandbox with cgroups. $ ls /home user1 $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs $ ls /home ls: cannot open directory '/home': Permission denied # Current limitations and possible improvements For now, eBPF programs can only return an errno code. It may be interesting to be able to do other actions like seccomp-filter does (e.g. kill process). Such features can easily be implemented but the main advantage of the current approach is to be able to only execute eBPF programs until one return an errno code instead of executing all programs like seccomp-filter does. It is quite easy to add new eBPF functions to extend Landlock. The main concern should be about the ability to leak information from the current process to another one (e.g. through maps) to not reproduce the same security sensitive behavior as ptrace. This design does not seems too intrusive but is flexible enough to allow a powerful sandbox mechanism accessible by any process on Linux. The use of seccomp and Landlock is more suitable with the help of a userland library (e.g. libseccomp) that could help to specify a high-level language to express a security policy instead of raw eBPF programs. Moreover, thanks to LLVM, it is possible to express an eBPF program with a subset of C. # FAQ ## Why not use a policy language like used by SElinux or AppArmor? This kind of LSMs are dedicated to administrators. They already manage the system and are not a threat to the system security. However, seccomp, and Landlock too, should be available to anyone, which potentially include untrusted users and processes. To reduce the attack surface, Landlock should expose the minimum amount of code, hence minimal complexity. Moreover, another threat is to make accessible to a malicious code a new way to gain more information. For example, Landlock features should not allow a program to get the file owner if the directory containing this file is not readable. This data could then be exfiltrated thanks to the access result. Thus, we should limit the expressiveness of the available checks. The current approach is to do the checks in such a way that only a comparison with an already accessed resource (e.g. file descriptor) is possible. This allow to have a reference to compare with, without exposing much information. ## Why a new LSM? Does SELinux, AppArmor, Smack or Tomoyo are not good enough? The current access control LSMs are fine for their purpose which is to give the *root* the ability to enforce a security policy for the *system*. What is missing is a way to enforce a security policy for any applications by its developer and *unprivileged user* as seccomp can do for raw syscall filtering. Moreover, Landlock handles stacked hook programs from different users. It must then ensure there is no possible malicious interactions between this programs. Difference with other (access control) LSMs: * not only dedicated to administrators (i.e. no_new_priv); * limited kernel attack surface (e.g. policy parsing); * helpers to compare complex objects (path/FD), no access to internal kernel data (do not leak addresses); * constraint policy rules/programs (no DoS: deterministic execution time); * do not leak more information than the loader process can legitimately have access to (minimize metadata inference): must compare from an already allowed file (through a handle). ## Why does seccomp-filter is not enough? A seccomp filter can access to raw syscall arguments which means that it is not possible to filter according to pointed data as a file path. As demonstrated the first version of this patch series, filtering at the syscall level is complicated (e.g. need to take care of race conditions). This is mainly because the access control checkpoints of the kernel are not at this high-level but more underneath, at LSM hooks level. The LSM hooks are designed to handle this kind of checks. This series use this approach to leverage the ability of unprivileged users to limit themselves. Cf. "What it isn't?" in Documentation/prctl/seccomp_filter.txt ## As a developer, why do I need this feature? Landlock's goal is to help userland to limit its attack surface. Security-conscious developers would like to protect users from a security bug in their applications and the third-party dependencies they are using. Such a bug can compromise all the user data and help an attacker to perform a privilege escalation. Using an *unprivileged sandbox* feature such as Landlock empower the developer with the ability to properly compartmentalize its software and limit the impact of being compromised. ## As a user, why do I need a this feature? Any user can already use seccomp-filter to whitelist a set of syscalls to reduce the kernel attack surface for a set of processes. However an unprivileged user can't create a security policy as the root user can thanks to SELinux and other access control LSMs. Landlock allows any unprivileged user to protect their data from being accessed by any process they run but only an identified subset. User tools can be created to help create such a high-level access control policy. This policy may not be powerful enough to express the same policies as the current access control LSMs, because of the threat an unprivileged user can be to the system, but it should be enough for most use-cases (e.g. blacklist or whitelist a set of file hierarchies). ## Does Landlock can limit network access or other resources? Limiting network access is obviously in the scope of Landlock but it is not yet implemented. The main goal now is to get feedback about the whole concept, the API and the file access control part. More access control types could be implemented in the future. ## Why using the seccomp(2) syscall? Landlock use the same semantic as seccomp to apply access rule restrictions. It add a new layer of security for the current process which is inherited by its childs. It make sense to use an unique access-restricting syscall (that should be allowed by seccomp-filter rules) which can only drop privileges. Moreover, a Landlock eBPF program could come from outside a process (e.g. passed through a UNIX socket). It is then useful to differentiate the creation/load of Landlock eBPF programs via bpf(2), from rule enforcing via seccomp(2). ## Why using cgroups? cgroups are designed to handle groups of processes. One use case is to manage containers. Sandboxing based on process hierarchy (seccomp) is design to handle immutable security policies, which is a good security property but does not match all use cases. A user can attach Landlock rules to a cgroup. Doing so, all the processes in that cgroup will be subject to the security policy. However, if the user is allowed to manage this cgroup, it could dynamically move this group of processes to a cgroup with another security policy (or none). Landlock rules can be applied either on a process hierarchy (e.g. application with built-in sandboxing) or a group of processes (e.g. container sandboxing). Both approaches can be combined for the same process. # Changes since RFC v2 * revamp cgroup handling: * use Daniel Mack's patches "Add eBPF hooks for cgroups" v5 [3] * remove bpf_landlock_cmp_cgroup_beneath() * make BPF_PROG_ATTACH usable with delegated cgroups * add a new CGRP_NO_NEW_PRIVS flag for safe cgroups * handle Landlock sandboxing for cgroups hierarchy * allow unprivileged processes to attach Landlock eBPF program to cgroups * add subtype to eBPF programs: * replace Landlock hook identification by custom eBPF program types with a dedicated subtype field * manage fine-grained privileged Landlock programs * register Landlock programs for dedicated trigger origins (e.g. syscall, return from seccomp filter and/or interruption) * performance and memory optimizations: use an array to access Landlock hooks directly but do not duplicated it for each thread (seccomp-based) * allow running Landlock programs without seccomp filter * fix seccomp-related issues * remove extra errno bounding check for Landlock programs * add some examples for optional eBPF functions or context access (network related) according to security checks to allow more features for privileged programs (e.g. Checmate) # Changes since RFC v1 * focus on the LSM hooks, not the syscalls: * much more simple implementation * does not need audit cache tricks to avoid race conditions * more simple to use and more generic because using the LSM hook abstraction directly * more efficient because only checking in LSM hooks * architecture agnostic * switch from cBPF to eBPF: * new eBPF program types dedicated to Landlock * custom functions used by the eBPF program * gain some new features (e.g. 10 registers, can load values of different size, LLVM translator) but only a few functions allowed and a dedicated map type * new context: LSM hook ID, cookie and LSM hook arguments * need to set the sysctl kernel.unprivileged_bpf_disable to 0 (default value) to be able to load hook filters as unprivileged users * smaller and simpler: * no more checker groups but dedicated arraymap of handles * simpler userland structs thanks to eBPF functions * distinctive name: Landlock This series can be applied on top of the Daniel Mack's patches for BPF_PROG_ATTACH v5 [3] on Linux next-20160913 (commit 562d4a2d7fa26b11d995f418951f3396a5d0f550). This can be tested with CONFIG_SECURITY_LANDLOCK, CONFIG_SECCOMP_FILTER and CONFIG_CGROUP_BPF. I would really appreciate constructive comments on the usability, architecture, code and userland API of Landlock LSM. [1] https://lkml.kernel.org/r/1472121165-29071-1-git-send-email-mic@digikod.net [2] https://crypto.stanford.edu/cs155/papers/traps.pdf [3] https://lkml.kernel.org/r/1473696735-11269-1-git-send-email-daniel@zonque.org Regards, Mickaël Salaün (22): landlock: Add Kconfig bpf: Move u64_to_ptr() to BPF headers and inline it bpf,landlock: Add a new arraymap type to deal with (Landlock) handles bpf: Set register type according to is_valid_access() bpf,landlock: Add eBPF program subtype and is_valid_subtype() verifier landlock: Add LSM hooks landlock: Handle file comparisons seccomp: Fix documentation for struct seccomp_filter seccomp: Move struct seccomp_filter in seccomp.h seccomp: Split put_seccomp_filter() with put_seccomp() seccomp,landlock: Handle Landlock hooks per process hierarchy bpf: Cosmetic change for bpf_prog_attach() bpf/cgroup: Replace struct bpf_prog with union bpf_object bpf/cgroup: Make cgroup_bpf_update() return an error code bpf/cgroup: Move capability check bpf/cgroup,landlock: Handle Landlock hooks per cgroup cgroup: Add access check for cgroup_get_from_fd() cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks landlock: Add interrupted origin landlock: Add update and debug access flags bpf,landlock: Add optional skb pointer in the Landlock context samples/landlock: Add sandbox example include/linux/bpf-cgroup.h | 19 +- include/linux/bpf.h | 45 +++- include/linux/cgroup-defs.h | 9 + include/linux/cgroup.h | 2 +- include/linux/filter.h | 1 + include/linux/landlock.h | 86 ++++++++ include/linux/lsm_hooks.h | 5 + include/linux/seccomp.h | 58 +++++- include/uapi/linux/bpf.h | 122 +++++++++++ include/uapi/linux/seccomp.h | 2 + kernel/bpf/arraymap.c | 226 ++++++++++++++++++++- kernel/bpf/cgroup.c | 78 ++++--- kernel/bpf/syscall.c | 78 ++++--- kernel/bpf/verifier.c | 47 ++++- kernel/cgroup.c | 66 +++++- kernel/fork.c | 25 ++- kernel/seccomp.c | 107 +++++++--- kernel/trace/bpf_trace.c | 12 +- net/core/filter.c | 21 +- samples/Makefile | 2 +- samples/landlock/.gitignore | 1 + samples/landlock/Makefile | 16 ++ samples/landlock/sandbox.c | 307 ++++++++++++++++++++++++++++ security/Kconfig | 1 + security/Makefile | 2 + security/landlock/Kconfig | 23 +++ security/landlock/Makefile | 3 + security/landlock/checker_fs.c | 179 ++++++++++++++++ security/landlock/checker_fs.h | 20 ++ security/landlock/common.h | 27 +++ security/landlock/lsm.c | 451 +++++++++++++++++++++++++++++++++++++++++ security/landlock/manager.c | 281 +++++++++++++++++++++++++ security/security.c | 1 + 33 files changed, 2194 insertions(+), 129 deletions(-) create mode 100644 include/linux/landlock.h create mode 100644 samples/landlock/.gitignore create mode 100644 samples/landlock/Makefile create mode 100644 samples/landlock/sandbox.c create mode 100644 security/landlock/Kconfig create mode 100644 security/landlock/Makefile create mode 100644 security/landlock/checker_fs.c create mode 100644 security/landlock/checker_fs.h create mode 100644 security/landlock/common.h create mode 100644 security/landlock/lsm.c create mode 100644 security/landlock/manager.c -- 2.9.3 From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= Subject: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing Date: Wed, 14 Sep 2016 09:23:53 +0200 Message-ID: <20160914072415.26021-1-mic@digikod.net> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger. To: linux-kernel@vger.kernel.org Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: netdev.vger.kernel.org Hi, This series, improvement of the previous RFC [1], is a proof of concept to fill some missing part of seccomp as the ability to check syscall argument pointers or creating more dynamic security policies. The goal of this new stackable Linux Security Module (LSM) called Landlock is to allow any process, including unprivileged ones, to create powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of bugs or unexpected/malicious behaviors in userland applications. # Landlock LSM This series is mainly focused on cgroups while keeping the possibility to enforce access rules through seccomp. eBPF programs are used to create a security rule. They are very limited (i.e. can only call a whitelist of functions) and can not do a denial of service (i.e. no loop). A new dedicated eBPF map allows to collect and compare Landlock handles with system resources (e.g. files or network connections). The approach taken is to add the minimum amount of code while still allowing the userland to create quite complex access rules. A dedicated security policy language such as used by SELinux, AppArmor and other major LSMs is a lot of code and dedicated to a trusted process (i.e. root/administrator). # eBPF To get an expressive language while still being safe and small, Landlock is based on eBPF. Landlock should be usable by untrusted processes and must then expose a minimal attack surface. The eBPF bytecode is minimal while powerful, widely used and thought to be used by not so trusted application. Reusing this code allows to not reproduce the same mistakes and minimize new code while still taking a generic approach. There is only some new features like a new kind of arraymap and few dedicated eBPF functions. An eBPF program have access to an eBPF context which contains the LSM hook arguments (as does seccomp-bpf with syscall arguments). They can be used directly or passed to helper functions according to their types. It is then possible to do complex access checks without race conditions nor inconsistent evaluation (i.e. incorrect mirroring of the OS code and state [2]). There is one eBPF program subtype per LSM hook. This allow to statically check which context access is performed by an eBPF program. This is needed to deny kernel address leak and ensure the right use of LSM hook arguments with eBPF functions. Moreover, this safe pointer handling remove the need for runtime check or abstract data, which improve performances. Any user can add multiple Landlock eBPF programs per LSM hook. They are stacked and evaluated one after the other (cf. seccomp-bpf). # LSM hooks Contrary to syscalls, LSM hooks are security checkpoints and are not architecture dependant. They are designed to match a security need reflected by a security policy (e.g. access to a file). Exposing parts of some LSM hooks instead of using the syscall API for sandboxing should help to avoid bugs and hacks as encountered by the first RFC. Instead of redoing the work of the LSM hooks through syscalls, we should use and expose them as does policies of access control LSM. Only a subset of the hooks are meaningful for an unprivileged sandbox mechanism (e.g. file system or network access control). Landlock use an abstraction of raw LSM hooks, which allow to deal with possible future API changes of the LSM hook API. Moreover, thanks to the ePBF program typing (per LSM hook) used by Landlock, it should not be hard to make such evolutions backward compatible. # Use case scenario First, a process need to create a new dedicated eBPF map containing handles. This handles are references to system resources (e.g. file or directory) and grouped in one or multiple maps to be efficiently managed and checked in batches. This kind of map can be passed to Landlock eBPF functions to compare, for example, with a file access request. The handles are only accessible from the eBPF programs created by the same thread. The loaded Landlock eBPF programs can be triggered by a seccomp filter returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from a seccomp filter to eBPF programs. This allow flexible security policies between seccomp and Landlock. Another way to enforce a Landlock security policy is to attach Landlock programs to a dedicated cgroup. All the processes in this cgroup will then be subject to this policy. For unprivileged processes, this can be done thanks to cgroup delegation. A triggered Landlock eBPF program can allows or deny an access, according to its subtype (i.e. LSM hook), thanks to errno return values. # Sandbox example with process hierarchy sandboxing (seccomp) $ ls /home user1 $ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox /bin/sh -i Launching a new sandboxed process. $ ls /home ls: cannot open directory '/home': Permission denied # Sandbox example with conditional access control depending on a cgroup $ mkdir /sys/fs/cgroup/sandboxed $ ls /home user1 $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox Ready to sandbox with cgroups. $ ls /home user1 $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs $ ls /home ls: cannot open directory '/home': Permission denied # Current limitations and possible improvements For now, eBPF programs can only return an errno code. It may be interesting to be able to do other actions like seccomp-filter does (e.g. kill process). Such features can easily be implemented but the main advantage of the current approach is to be able to only execute eBPF programs until one return an errno code instead of executing all programs like seccomp-filter does. It is quite easy to add new eBPF functions to extend Landlock. The main concern should be about the ability to leak information from the current process to another one (e.g. through maps) to not reproduce the same security sensitive behavior as ptrace. This design does not seems too intrusive but is flexible enough to allow a powerful sandbox mechanism accessible by any process on Linux. The use of seccomp and Landlock is more suitable with the help of a userland library (e.g. libseccomp) that could help to specify a high-level language to express a security policy instead of raw eBPF programs. Moreover, thanks to LLVM, it is possible to express an eBPF program with a subset of C. # FAQ ## Why not use a policy language like used by SElinux or AppArmor? This kind of LSMs are dedicated to administrators. They already manage the system and are not a threat to the system security. However, seccomp, and Landlock too, should be available to anyone, which potentially include untrusted users and processes. To reduce the attack surface, Landlock should expose the minimum amount of code, hence minimal complexity. Moreover, another threat is to make accessible to a malicious code a new way to gain more information. For example, Landlock features should not allow a program to get the file owner if the directory containing this file is not readable. This data could then be exfiltrated thanks to the access result. Thus, we should limit the expressiveness of the available checks. The current approach is to do the checks in such a way that only a comparison with an already accessed resource (e.g. file descriptor) is possible. This allow to have a reference to compare with, without exposing much information. ## Why a new LSM? Does SELinux, AppArmor, Smack or Tomoyo are not good enough? The current access control LSMs are fine for their purpose which is to give the *root* the ability to enforce a security policy for the *system*. What is missing is a way to enforce a security policy for any applications by its developer and *unprivileged user* as seccomp can do for raw syscall filtering. Moreover, Landlock handles stacked hook programs from different users. It must then ensure there is no possible malicious interactions between this programs. Difference with other (access control) LSMs: * not only dedicated to administrators (i.e. no_new_priv); * limited kernel attack surface (e.g. policy parsing); * helpers to compare complex objects (path/FD), no access to internal kernel data (do not leak addresses); * constraint policy rules/programs (no DoS: deterministic execution time); * do not leak more information than the loader process can legitimately have access to (minimize metadata inference): must compare from an already allowed file (through a handle). ## Why does seccomp-filter is not enough? A seccomp filter can access to raw syscall arguments which means that it is not possible to filter according to pointed data as a file path. As demonstrated the first version of this patch series, filtering at the syscall level is complicated (e.g. need to take care of race conditions). This is mainly because the access control checkpoints of the kernel are not at this high-level but more underneath, at LSM hooks level. The LSM hooks are designed to handle this kind of checks. This series use this approach to leverage the ability of unprivileged users to limit themselves. Cf. "What it isn't?" in Documentation/prctl/seccomp_filter.txt ## As a developer, why do I need this feature? Landlock's goal is to help userland to limit its attack surface. Security-conscious developers would like to protect users from a security bug in their applications and the third-party dependencies they are using. Such a bug can compromise all the user data and help an attacker to perform a privilege escalation. Using an *unprivileged sandbox* feature such as Landlock empower the developer with the ability to properly compartmentalize its software and limit the impact of being compromised. ## As a user, why do I need a this feature? Any user can already use seccomp-filter to whitelist a set of syscalls to reduce the kernel attack surface for a set of processes. However an unprivileged user can't create a security policy as the root user can thanks to SELinux and other access control LSMs. Landlock allows any unprivileged user to protect their data from being accessed by any process they run but only an identified subset. User tools can be created to help create such a high-level access control policy. This policy may not be powerful enough to express the same policies as the current access control LSMs, because of the threat an unprivileged user can be to the system, but it should be enough for most use-cases (e.g. blacklist or whitelist a set of file hierarchies). ## Does Landlock can limit network access or other resources? Limiting network access is obviously in the scope of Landlock but it is not yet implemented. The main goal now is to get feedback about the whole concept, the API and the file access control part. More access control types could be implemented in the future. ## Why using the seccomp(2) syscall? Landlock use the same semantic as seccomp to apply access rule restrictions. It add a new layer of security for the current process which is inherited by its childs. It make sense to use an unique access-restricting syscall (that should be allowed by seccomp-filter rules) which can only drop privileges. Moreover, a Landlock eBPF program could come from outside a process (e.g. passed through a UNIX socket). It is then useful to differentiate the creation/load of Landlock eBPF programs via bpf(2), from rule enforcing via seccomp(2). ## Why using cgroups? cgroups are designed to handle groups of processes. One use case is to manage containers. Sandboxing based on process hierarchy (seccomp) is design to handle immutable security policies, which is a good security property but does not match all use cases. A user can attach Landlock rules to a cgroup. Doing so, all the processes in that cgroup will be subject to the security policy. However, if the user is allowed to manage this cgroup, it could dynamically move this group of processes to a cgroup with another security policy (or none). Landlock rules can be applied either on a process hierarchy (e.g. application with built-in sandboxing) or a group of processes (e.g. container sandboxing). Both approaches can be combined for the same process. # Changes since RFC v2 * revamp cgroup handling: * use Daniel Mack's patches "Add eBPF hooks for cgroups" v5 [3] * remove bpf_landlock_cmp_cgroup_beneath() * make BPF_PROG_ATTACH usable with delegated cgroups * add a new CGRP_NO_NEW_PRIVS flag for safe cgroups * handle Landlock sandboxing for cgroups hierarchy * allow unprivileged processes to attach Landlock eBPF program to cgroups * add subtype to eBPF programs: * replace Landlock hook identification by custom eBPF program types with a dedicated subtype field * manage fine-grained privileged Landlock programs * register Landlock programs for dedicated trigger origins (e.g. syscall, return from seccomp filter and/or interruption) * performance and memory optimizations: use an array to access Landlock hooks directly but do not duplicated it for each thread (seccomp-based) * allow running Landlock programs without seccomp filter * fix seccomp-related issues * remove extra errno bounding check for Landlock programs * add some examples for optional eBPF functions or context access (network related) according to security checks to allow more features for privileged programs (e.g. Checmate) # Changes since RFC v1 * focus on the LSM hooks, not the syscalls: * much more simple implementation * does not need audit cache tricks to avoid race conditions * more simple to use and more generic because using the LSM hook abstraction directly * more efficient because only checking in LSM hooks * architecture agnostic * switch from cBPF to eBPF: * new eBPF program types dedicated to Landlock * custom functions used by the eBPF program * gain some new features (e.g. 10 registers, can load values of different size, LLVM translator) but only a few functions allowed and a dedicated map type * new context: LSM hook ID, cookie and LSM hook arguments * need to set the sysctl kernel.unprivileged_bpf_disable to 0 (default value) to be able to load hook filters as unprivileged users * smaller and simpler: * no more checker groups but dedicated arraymap of handles * simpler userland structs thanks to eBPF functions * distinctive name: Landlock This series can be applied on top of the Daniel Mack's patches for BPF_PROG_ATTACH v5 [3] on Linux next-20160913 (commit 562d4a2d7fa26b11d995f418951f3396a5d0f550). This can be tested with CONFIG_SECURITY_LANDLOCK, CONFIG_SECCOMP_FILTER and CONFIG_CGROUP_BPF. I would really appreciate constructive comments on the usability, architecture, code and userland API of Landlock LSM. [1] https://lkml.kernel.org/r/1472121165-29071-1-git-send-email-mic@digikod.net [2] https://crypto.stanford.edu/cs155/papers/traps.pdf [3] https://lkml.kernel.org/r/1473696735-11269-1-git-send-email-daniel@zonque.org Regards, Mickaël Salaün (22): landlock: Add Kconfig bpf: Move u64_to_ptr() to BPF headers and inline it bpf,landlock: Add a new arraymap type to deal with (Landlock) handles bpf: Set register type according to is_valid_access() bpf,landlock: Add eBPF program subtype and is_valid_subtype() verifier landlock: Add LSM hooks landlock: Handle file comparisons seccomp: Fix documentation for struct seccomp_filter seccomp: Move struct seccomp_filter in seccomp.h seccomp: Split put_seccomp_filter() with put_seccomp() seccomp,landlock: Handle Landlock hooks per process hierarchy bpf: Cosmetic change for bpf_prog_attach() bpf/cgroup: Replace struct bpf_prog with union bpf_object bpf/cgroup: Make cgroup_bpf_update() return an error code bpf/cgroup: Move capability check bpf/cgroup,landlock: Handle Landlock hooks per cgroup cgroup: Add access check for cgroup_get_from_fd() cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks landlock: Add interrupted origin landlock: Add update and debug access flags bpf,landlock: Add optional skb pointer in the Landlock context samples/landlock: Add sandbox example include/linux/bpf-cgroup.h | 19 +- include/linux/bpf.h | 45 +++- include/linux/cgroup-defs.h | 9 + include/linux/cgroup.h | 2 +- include/linux/filter.h | 1 + include/linux/landlock.h | 86 ++++++++ include/linux/lsm_hooks.h | 5 + include/linux/seccomp.h | 58 +++++- include/uapi/linux/bpf.h | 122 +++++++++++ include/uapi/linux/seccomp.h | 2 + kernel/bpf/arraymap.c | 226 ++++++++++++++++++++- kernel/bpf/cgroup.c | 78 ++++--- kernel/bpf/syscall.c | 78 ++++--- kernel/bpf/verifier.c | 47 ++++- kernel/cgroup.c | 66 +++++- kernel/fork.c | 25 ++- kernel/seccomp.c | 107 +++++++--- kernel/trace/bpf_trace.c | 12 +- net/core/filter.c | 21 +- samples/Makefile | 2 +- samples/landlock/.gitignore | 1 + samples/landlock/Makefile | 16 ++ samples/landlock/sandbox.c | 307 ++++++++++++++++++++++++++++ security/Kconfig | 1 + security/Makefile | 2 + security/landlock/Kconfig | 23 +++ security/landlock/Makefile | 3 + security/landlock/checker_fs.c | 179 ++++++++++++++++ security/landlock/checker_fs.h | 20 ++ security/landlock/common.h | 27 +++ security/landlock/lsm.c | 451 +++++++++++++++++++++++++++++++++++++++++ security/landlock/manager.c | 281 +++++++++++++++++++++++++ security/security.c | 1 + 33 files changed, 2194 insertions(+), 129 deletions(-) create mode 100644 include/linux/landlock.h create mode 100644 samples/landlock/.gitignore create mode 100644 samples/landlock/Makefile create mode 100644 samples/landlock/sandbox.c create mode 100644 security/landlock/Kconfig create mode 100644 security/landlock/Makefile create mode 100644 security/landlock/checker_fs.c create mode 100644 security/landlock/checker_fs.h create mode 100644 security/landlock/common.h create mode 100644 security/landlock/lsm.c create mode 100644 security/landlock/manager.c -- 2.9.3 From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= Date: Wed, 14 Sep 2016 09:23:53 +0200 Message-Id: <20160914072415.26021-1-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [kernel-hardening] [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing To: linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org List-ID: Hi, This series, improvement of the previous RFC [1], is a proof of concept to fill some missing part of seccomp as the ability to check syscall argument pointers or creating more dynamic security policies. The goal of this new stackable Linux Security Module (LSM) called Landlock is to allow any process, including unprivileged ones, to create powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of bugs or unexpected/malicious behaviors in userland applications. # Landlock LSM This series is mainly focused on cgroups while keeping the possibility to enforce access rules through seccomp. eBPF programs are used to create a security rule. They are very limited (i.e. can only call a whitelist of functions) and can not do a denial of service (i.e. no loop). A new dedicated eBPF map allows to collect and compare Landlock handles with system resources (e.g. files or network connections). The approach taken is to add the minimum amount of code while still allowing the userland to create quite complex access rules. A dedicated security policy language such as used by SELinux, AppArmor and other major LSMs is a lot of code and dedicated to a trusted process (i.e. root/administrator). # eBPF To get an expressive language while still being safe and small, Landlock is based on eBPF. Landlock should be usable by untrusted processes and must then expose a minimal attack surface. The eBPF bytecode is minimal while powerful, widely used and thought to be used by not so trusted application. Reusing this code allows to not reproduce the same mistakes and minimize new code while still taking a generic approach. There is only some new features like a new kind of arraymap and few dedicated eBPF functions. An eBPF program have access to an eBPF context which contains the LSM hook arguments (as does seccomp-bpf with syscall arguments). They can be used directly or passed to helper functions according to their types. It is then possible to do complex access checks without race conditions nor inconsistent evaluation (i.e. incorrect mirroring of the OS code and state [2]). There is one eBPF program subtype per LSM hook. This allow to statically check which context access is performed by an eBPF program. This is needed to deny kernel address leak and ensure the right use of LSM hook arguments with eBPF functions. Moreover, this safe pointer handling remove the need for runtime check or abstract data, which improve performances. Any user can add multiple Landlock eBPF programs per LSM hook. They are stacked and evaluated one after the other (cf. seccomp-bpf). # LSM hooks Contrary to syscalls, LSM hooks are security checkpoints and are not architecture dependant. They are designed to match a security need reflected by a security policy (e.g. access to a file). Exposing parts of some LSM hooks instead of using the syscall API for sandboxing should help to avoid bugs and hacks as encountered by the first RFC. Instead of redoing the work of the LSM hooks through syscalls, we should use and expose them as does policies of access control LSM. Only a subset of the hooks are meaningful for an unprivileged sandbox mechanism (e.g. file system or network access control). Landlock use an abstraction of raw LSM hooks, which allow to deal with possible future API changes of the LSM hook API. Moreover, thanks to the ePBF program typing (per LSM hook) used by Landlock, it should not be hard to make such evolutions backward compatible. # Use case scenario First, a process need to create a new dedicated eBPF map containing handles. This handles are references to system resources (e.g. file or directory) and grouped in one or multiple maps to be efficiently managed and checked in batches. This kind of map can be passed to Landlock eBPF functions to compare, for example, with a file access request. The handles are only accessible from the eBPF programs created by the same thread. The loaded Landlock eBPF programs can be triggered by a seccomp filter returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from a seccomp filter to eBPF programs. This allow flexible security policies between seccomp and Landlock. Another way to enforce a Landlock security policy is to attach Landlock programs to a dedicated cgroup. All the processes in this cgroup will then be subject to this policy. For unprivileged processes, this can be done thanks to cgroup delegation. A triggered Landlock eBPF program can allows or deny an access, according to its subtype (i.e. LSM hook), thanks to errno return values. # Sandbox example with process hierarchy sandboxing (seccomp) $ ls /home user1 $ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox /bin/sh -i Launching a new sandboxed process. $ ls /home ls: cannot open directory '/home': Permission denied # Sandbox example with conditional access control depending on a cgroup $ mkdir /sys/fs/cgroup/sandboxed $ ls /home user1 $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \ LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \ ./samples/landlock/sandbox Ready to sandbox with cgroups. $ ls /home user1 $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs $ ls /home ls: cannot open directory '/home': Permission denied # Current limitations and possible improvements For now, eBPF programs can only return an errno code. It may be interesting to be able to do other actions like seccomp-filter does (e.g. kill process). Such features can easily be implemented but the main advantage of the current approach is to be able to only execute eBPF programs until one return an errno code instead of executing all programs like seccomp-filter does. It is quite easy to add new eBPF functions to extend Landlock. The main concern should be about the ability to leak information from the current process to another one (e.g. through maps) to not reproduce the same security sensitive behavior as ptrace. This design does not seems too intrusive but is flexible enough to allow a powerful sandbox mechanism accessible by any process on Linux. The use of seccomp and Landlock is more suitable with the help of a userland library (e.g. libseccomp) that could help to specify a high-level language to express a security policy instead of raw eBPF programs. Moreover, thanks to LLVM, it is possible to express an eBPF program with a subset of C. # FAQ ## Why not use a policy language like used by SElinux or AppArmor? This kind of LSMs are dedicated to administrators. They already manage the system and are not a threat to the system security. However, seccomp, and Landlock too, should be available to anyone, which potentially include untrusted users and processes. To reduce the attack surface, Landlock should expose the minimum amount of code, hence minimal complexity. Moreover, another threat is to make accessible to a malicious code a new way to gain more information. For example, Landlock features should not allow a program to get the file owner if the directory containing this file is not readable. This data could then be exfiltrated thanks to the access result. Thus, we should limit the expressiveness of the available checks. The current approach is to do the checks in such a way that only a comparison with an already accessed resource (e.g. file descriptor) is possible. This allow to have a reference to compare with, without exposing much information. ## Why a new LSM? Does SELinux, AppArmor, Smack or Tomoyo are not good enough? The current access control LSMs are fine for their purpose which is to give the *root* the ability to enforce a security policy for the *system*. What is missing is a way to enforce a security policy for any applications by its developer and *unprivileged user* as seccomp can do for raw syscall filtering. Moreover, Landlock handles stacked hook programs from different users. It must then ensure there is no possible malicious interactions between this programs. Difference with other (access control) LSMs: * not only dedicated to administrators (i.e. no_new_priv); * limited kernel attack surface (e.g. policy parsing); * helpers to compare complex objects (path/FD), no access to internal kernel data (do not leak addresses); * constraint policy rules/programs (no DoS: deterministic execution time); * do not leak more information than the loader process can legitimately have access to (minimize metadata inference): must compare from an already allowed file (through a handle). ## Why does seccomp-filter is not enough? A seccomp filter can access to raw syscall arguments which means that it is not possible to filter according to pointed data as a file path. As demonstrated the first version of this patch series, filtering at the syscall level is complicated (e.g. need to take care of race conditions). This is mainly because the access control checkpoints of the kernel are not at this high-level but more underneath, at LSM hooks level. The LSM hooks are designed to handle this kind of checks. This series use this approach to leverage the ability of unprivileged users to limit themselves. Cf. "What it isn't?" in Documentation/prctl/seccomp_filter.txt ## As a developer, why do I need this feature? Landlock's goal is to help userland to limit its attack surface. Security-conscious developers would like to protect users from a security bug in their applications and the third-party dependencies they are using. Such a bug can compromise all the user data and help an attacker to perform a privilege escalation. Using an *unprivileged sandbox* feature such as Landlock empower the developer with the ability to properly compartmentalize its software and limit the impact of being compromised. ## As a user, why do I need a this feature? Any user can already use seccomp-filter to whitelist a set of syscalls to reduce the kernel attack surface for a set of processes. However an unprivileged user can't create a security policy as the root user can thanks to SELinux and other access control LSMs. Landlock allows any unprivileged user to protect their data from being accessed by any process they run but only an identified subset. User tools can be created to help create such a high-level access control policy. This policy may not be powerful enough to express the same policies as the current access control LSMs, because of the threat an unprivileged user can be to the system, but it should be enough for most use-cases (e.g. blacklist or whitelist a set of file hierarchies). ## Does Landlock can limit network access or other resources? Limiting network access is obviously in the scope of Landlock but it is not yet implemented. The main goal now is to get feedback about the whole concept, the API and the file access control part. More access control types could be implemented in the future. ## Why using the seccomp(2) syscall? Landlock use the same semantic as seccomp to apply access rule restrictions. It add a new layer of security for the current process which is inherited by its childs. It make sense to use an unique access-restricting syscall (that should be allowed by seccomp-filter rules) which can only drop privileges. Moreover, a Landlock eBPF program could come from outside a process (e.g. passed through a UNIX socket). It is then useful to differentiate the creation/load of Landlock eBPF programs via bpf(2), from rule enforcing via seccomp(2). ## Why using cgroups? cgroups are designed to handle groups of processes. One use case is to manage containers. Sandboxing based on process hierarchy (seccomp) is design to handle immutable security policies, which is a good security property but does not match all use cases. A user can attach Landlock rules to a cgroup. Doing so, all the processes in that cgroup will be subject to the security policy. However, if the user is allowed to manage this cgroup, it could dynamically move this group of processes to a cgroup with another security policy (or none). Landlock rules can be applied either on a process hierarchy (e.g. application with built-in sandboxing) or a group of processes (e.g. container sandboxing). Both approaches can be combined for the same process. # Changes since RFC v2 * revamp cgroup handling: * use Daniel Mack's patches "Add eBPF hooks for cgroups" v5 [3] * remove bpf_landlock_cmp_cgroup_beneath() * make BPF_PROG_ATTACH usable with delegated cgroups * add a new CGRP_NO_NEW_PRIVS flag for safe cgroups * handle Landlock sandboxing for cgroups hierarchy * allow unprivileged processes to attach Landlock eBPF program to cgroups * add subtype to eBPF programs: * replace Landlock hook identification by custom eBPF program types with a dedicated subtype field * manage fine-grained privileged Landlock programs * register Landlock programs for dedicated trigger origins (e.g. syscall, return from seccomp filter and/or interruption) * performance and memory optimizations: use an array to access Landlock hooks directly but do not duplicated it for each thread (seccomp-based) * allow running Landlock programs without seccomp filter * fix seccomp-related issues * remove extra errno bounding check for Landlock programs * add some examples for optional eBPF functions or context access (network related) according to security checks to allow more features for privileged programs (e.g. Checmate) # Changes since RFC v1 * focus on the LSM hooks, not the syscalls: * much more simple implementation * does not need audit cache tricks to avoid race conditions * more simple to use and more generic because using the LSM hook abstraction directly * more efficient because only checking in LSM hooks * architecture agnostic * switch from cBPF to eBPF: * new eBPF program types dedicated to Landlock * custom functions used by the eBPF program * gain some new features (e.g. 10 registers, can load values of different size, LLVM translator) but only a few functions allowed and a dedicated map type * new context: LSM hook ID, cookie and LSM hook arguments * need to set the sysctl kernel.unprivileged_bpf_disable to 0 (default value) to be able to load hook filters as unprivileged users * smaller and simpler: * no more checker groups but dedicated arraymap of handles * simpler userland structs thanks to eBPF functions * distinctive name: Landlock This series can be applied on top of the Daniel Mack's patches for BPF_PROG_ATTACH v5 [3] on Linux next-20160913 (commit 562d4a2d7fa26b11d995f418951f3396a5d0f550). This can be tested with CONFIG_SECURITY_LANDLOCK, CONFIG_SECCOMP_FILTER and CONFIG_CGROUP_BPF. I would really appreciate constructive comments on the usability, architecture, code and userland API of Landlock LSM. [1] https://lkml.kernel.org/r/1472121165-29071-1-git-send-email-mic@digikod.net [2] https://crypto.stanford.edu/cs155/papers/traps.pdf [3] https://lkml.kernel.org/r/1473696735-11269-1-git-send-email-daniel@zonque.org Regards, Mickaël Salaün (22): landlock: Add Kconfig bpf: Move u64_to_ptr() to BPF headers and inline it bpf,landlock: Add a new arraymap type to deal with (Landlock) handles bpf: Set register type according to is_valid_access() bpf,landlock: Add eBPF program subtype and is_valid_subtype() verifier landlock: Add LSM hooks landlock: Handle file comparisons seccomp: Fix documentation for struct seccomp_filter seccomp: Move struct seccomp_filter in seccomp.h seccomp: Split put_seccomp_filter() with put_seccomp() seccomp,landlock: Handle Landlock hooks per process hierarchy bpf: Cosmetic change for bpf_prog_attach() bpf/cgroup: Replace struct bpf_prog with union bpf_object bpf/cgroup: Make cgroup_bpf_update() return an error code bpf/cgroup: Move capability check bpf/cgroup,landlock: Handle Landlock hooks per cgroup cgroup: Add access check for cgroup_get_from_fd() cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks landlock: Add interrupted origin landlock: Add update and debug access flags bpf,landlock: Add optional skb pointer in the Landlock context samples/landlock: Add sandbox example include/linux/bpf-cgroup.h | 19 +- include/linux/bpf.h | 45 +++- include/linux/cgroup-defs.h | 9 + include/linux/cgroup.h | 2 +- include/linux/filter.h | 1 + include/linux/landlock.h | 86 ++++++++ include/linux/lsm_hooks.h | 5 + include/linux/seccomp.h | 58 +++++- include/uapi/linux/bpf.h | 122 +++++++++++ include/uapi/linux/seccomp.h | 2 + kernel/bpf/arraymap.c | 226 ++++++++++++++++++++- kernel/bpf/cgroup.c | 78 ++++--- kernel/bpf/syscall.c | 78 ++++--- kernel/bpf/verifier.c | 47 ++++- kernel/cgroup.c | 66 +++++- kernel/fork.c | 25 ++- kernel/seccomp.c | 107 +++++++--- kernel/trace/bpf_trace.c | 12 +- net/core/filter.c | 21 +- samples/Makefile | 2 +- samples/landlock/.gitignore | 1 + samples/landlock/Makefile | 16 ++ samples/landlock/sandbox.c | 307 ++++++++++++++++++++++++++++ security/Kconfig | 1 + security/Makefile | 2 + security/landlock/Kconfig | 23 +++ security/landlock/Makefile | 3 + security/landlock/checker_fs.c | 179 ++++++++++++++++ security/landlock/checker_fs.h | 20 ++ security/landlock/common.h | 27 +++ security/landlock/lsm.c | 451 +++++++++++++++++++++++++++++++++++++++++ security/landlock/manager.c | 281 +++++++++++++++++++++++++ security/security.c | 1 + 33 files changed, 2194 insertions(+), 129 deletions(-) create mode 100644 include/linux/landlock.h create mode 100644 samples/landlock/.gitignore create mode 100644 samples/landlock/Makefile create mode 100644 samples/landlock/sandbox.c create mode 100644 security/landlock/Kconfig create mode 100644 security/landlock/Makefile create mode 100644 security/landlock/checker_fs.c create mode 100644 security/landlock/checker_fs.h create mode 100644 security/landlock/common.h create mode 100644 security/landlock/lsm.c create mode 100644 security/landlock/manager.c -- 2.9.3