From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: KP Singh <kpsingh@chromium.org> Cc: "open list" <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>, linux-security-module@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Daniel Borkmann" <daniel@iogearbox.net>, "James Morris" <jmorris@namei.org>, "Kees Cook" <keescook@chromium.org>, "Thomas Garnier" <thgarnie@chromium.org>, "Michael Halcrow" <mhalcrow@google.com>, "Paul Turner" <pjt@google.com>, "Brendan Gregg" <brendan.d.gregg@gmail.com>, "Jann Horn" <jannh@google.com>, "Matthew Garrett" <mjg59@google.com>, "Christian Brauner" <christian@brauner.io>, "Mickaël Salaün" <mic@digikod.net>, "Florent Revest" <revest@chromium.org>, "Brendan Jackman" <jackmanb@chromium.org>, "Martin KaFai Lau" <kafai@fb.com>, "Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>, "David S. Miller" <davem@davemloft.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Nicolas Ferre" <nicolas.ferre@microchip.com>, "Stanislav Fomichev" <sdf@google.com>, "Quentin Monnet" <quentin.monnet@netronome.com>, "Andrey Ignatov" <rdna@fb.com>, "Joe Stringer" <joe@wand.net.nz> Subject: Re: [PATCH bpf-next v2 00/10] MAC and Audit policy using eBPF (KRSI) Date: Wed, 15 Jan 2020 14:12:55 -0800 Message-ID: <CAEf4BzbCT8_LvgyeOtfjx7tm+Q41iGEmjvHwSkR=aBoBs3xVZA@mail.gmail.com> (raw) In-Reply-To: <20200115171333.28811-1-kpsingh@chromium.org> On Wed, Jan 15, 2020 at 9:15 AM KP Singh <kpsingh@chromium.org> wrote: > > From: KP Singh <kpsingh@google.com> > > # Changes since v1 (https://lore.kernel.org/bpf/20191220154208.15895-1-kpsingh@chromium.org/): > > * Eliminate the requirement to maintain LSM hooks separately in > security/bpf/hooks.h Use BPF trampolines to dynamically allocate > security hooks > * Drop the use of securityfs as bpftool provides the required > introspection capabilities. Update the tests to use the bpf_skeleton > and global variables > * Use O_CLOEXEC anonymous fds to represent BPF attachment in line with > the other BPF programs with the possibility to use bpf program pinning > in the future to provide "permanent attachment". > * Drop the logic based on prog names for handling re-attachment. > * Drop bpf_lsm_event_output from this series and send it as a separate > patch. > > # Motivation > > Google does analysis of rich runtime security data to detect and thwart > threats in real-time. Currently, this is done in custom kernel modules > but we would like to replace this with something that's upstream and > useful to others. > > The current kernel infrastructure for providing telemetry (Audit, Perf > etc.) is disjoint from access enforcement (i.e. LSMs). Augmenting the > information provided by audit requires kernel changes to audit, its > policy language and user-space components. Furthermore, building a MAC > policy based on the newly added telemetry data requires changes to > various LSMs and their respective policy languages. > > This patchset proposes a new stackable and privileged LSM which allows > the LSM hooks to be implemented using eBPF. This facilitates a unified > and dynamic (not requiring re-compilation of the kernel) audit and MAC > policy. > > # Why an LSM? > > Linux Security Modules target security behaviours rather than the > kernel's API. For example, it's easy to miss out a newly added system > call for executing processes (eg. execve, execveat etc.) but the LSM > framework ensures that all process executions trigger the relevant hooks > irrespective of how the process was executed. > > Allowing users to implement LSM hooks at runtime also benefits the LSM > eco-system by enabling a quick feedback loop from the security community > about the kind of behaviours that the LSM Framework should be targeting. > > # How does it work? > > The LSM introduces a new eBPF (https://docs.cilium.io/en/v1.6/bpf/) > program type BPF_PROG_TYPE_LSM which can only be attached to LSM hooks. > Attachment requires CAP_SYS_ADMIN for loading eBPF programs and > CAP_MAC_ADMIN for modifying MAC policies. > > The eBPF programs are attached to a separate security_hook_heads > maintained by the BPF LSM for mutable hooks and executed after all the > statically defined hooks (i.e. the ones declared by SELinux, AppArmor, > Smack etc). This also ensures that statically defined LSM hooks retain > the behaviour of "being read-only after init", i.e. __lsm_ro_after_init. > > Upon attachment, a security hook is dynamically allocated with > arch_bpf_prepare_trampoline which generates code to handle the > conversion from the signature of the hook to the BPF context and allows > the JIT'ed BPF program to be called as a C function with the same > arguments as the LSM hooks. If any of the attached eBPF programs returns > an error (like ENOPERM), the behaviour represented by the hook is > denied. > > Audit logs can be written using a format chosen by the eBPF program to > the perf events buffer or to global eBPF variables or maps and can be > further processed in user-space. > > # BTF Based Design > > The current design uses BTF > (https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html, > https://lwn.net/Articles/803258/) which allows verifiable read-only > structure accesses by field names rather than fixed offsets. This allows > accessing the hook parameters using a dynamically created context which > provides a certain degree of ABI stability: > > > // Only declare the structure and fields intended to be used > // in the program > struct vm_area_struct { > unsigned long vm_start; > } __attribute__((preserve_access_index)); > It would be nice to also mention that you don't even have to "re-define" these structs if you use vmlinux.h generated with `bpftool btf dump file <path-to-vm-linux-or-/sys/kernel/btf/vmlinux> format c`. Its output will contain all types of the kernel, including internal ones not exposed through any public headers. And it will also automatically have __attribute__((preserve_access_index)) applied to all structs/unions. It can be pre-generated and checked in somewhere along the application or generated on the fly, if environment and use case allows. > // Declare the eBPF program mprotect_audit which attaches to > // to the file_mprotect LSM hook and accepts three arguments. > SEC("lsm/file_mprotect") > int BPF_PROG(mprotect_audit, struct vm_area_struct *vma, > unsigned long reqprot, unsigned long prot) > { > unsigned long vm_start = vma->vm_start; > > return 0; > } > > By relocating field offsets, BTF makes a large portion of kernel data > structures readily accessible across kernel versions without requiring a > large corpus of BPF helper functions and requiring recompilation with > every kernel version. The BTF type information is also used by the BPF > verifier to validate memory accesses within the BPF program and also > prevents arbitrary writes to the kernel memory. > > The limitations of BTF compatibility are described in BPF Co-Re > (http://vger.kernel.org/bpfconf2019_talks/bpf-core.pdf, i.e. field > renames, #defines and changes to the signature of LSM hooks). > > This design imposes that the MAC policy (eBPF programs) be updated when > the inspected kernel structures change outside of BTF compatibility > guarantees. In practice, this is only required when a structure field > used by a current policy is removed (or renamed) or when the used LSM > hooks change. We expect the maintenance cost of these changes to be > acceptable as compared to the previous design > (https://lore.kernel.org/bpf/20190910115527.5235-1-kpsingh@chromium.org/). > [...]
next prev parent reply index Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-15 17:13 KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 01/10] bpf: btf: Make some of the API visible outside BTF KP Singh 2020-01-18 12:44 ` kbuild test robot 2020-01-20 11:00 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 02/10] bpf: lsm: Add a skeleton and config options KP Singh 2020-01-16 7:04 ` Casey Schaufler 2020-01-16 12:52 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 03/10] bpf: lsm: Introduce types for eBPF based LSM KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM KP Singh 2020-01-15 17:30 ` Stephen Smalley 2020-01-16 9:48 ` KP Singh 2020-01-16 6:33 ` Casey Schaufler 2020-01-16 10:19 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 05/10] bpf: lsm: BTF API for LSM hooks KP Singh 2020-01-17 0:28 ` Andrii Nakryiko 2020-01-20 11:10 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 06/10] bpf: lsm: Implement attach, detach and execution KP Singh 2020-01-15 17:24 ` Greg Kroah-Hartman 2020-01-16 9:45 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 07/10] bpf: lsm: Make the allocated callback RO+X KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 08/10] tools/libbpf: Add support for BPF_PROG_TYPE_LSM KP Singh 2020-01-15 21:19 ` Andrii Nakryiko 2020-01-15 21:37 ` Andrii Nakryiko 2020-01-16 12:49 ` KP Singh 2020-01-16 17:26 ` KP Singh 2020-01-16 19:10 ` Andrii Nakryiko 2020-01-17 22:16 ` KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 09/10] bpf: lsm: Add selftests " KP Singh 2020-01-15 17:13 ` [PATCH bpf-next v2 10/10] bpf: lsm: Add Documentation KP Singh 2020-01-15 22:12 ` Andrii Nakryiko [this message] 2020-01-20 11:12 ` [PATCH bpf-next v2 00/10] MAC and Audit policy using eBPF (KRSI) KP Singh 2020-01-16 10:03 ` Brendan Jackman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAEf4BzbCT8_LvgyeOtfjx7tm+Q41iGEmjvHwSkR=aBoBs3xVZA@mail.gmail.com' \ --to=andrii.nakryiko@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=brendan.d.gregg@gmail.com \ --cc=christian@brauner.io \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=gregkh@linuxfoundation.org \ --cc=jackmanb@chromium.org \ --cc=jannh@google.com \ --cc=jmorris@namei.org \ --cc=joe@wand.net.nz \ --cc=kafai@fb.com \ --cc=keescook@chromium.org \ --cc=kpsingh@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mchehab+samsung@kernel.org \ --cc=mhalcrow@google.com \ --cc=mic@digikod.net \ --cc=mjg59@google.com \ --cc=nicolas.ferre@microchip.com \ --cc=pjt@google.com \ --cc=quentin.monnet@netronome.com \ --cc=rdna@fb.com \ --cc=revest@chromium.org \ --cc=sdf@google.com \ --cc=serge@hallyn.com \ --cc=songliubraving@fb.com \ --cc=thgarnie@chromium.org \ --cc=yhs@fb.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ linux-security-module@vger.kernel.org public-inbox-index linux-security-module Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/public-inbox.git