From: "Dr. Greg" <firstname.lastname@example.org> To: KP Singh <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Alexei Starovoitov <email@example.com>, Daniel Borkmann <firstname.lastname@example.org>, James Morris <email@example.com>, Kees Cook <firstname.lastname@example.org>, Thomas Garnier <email@example.com>, Michael Halcrow <firstname.lastname@example.org>, Paul Turner <email@example.com>, Brendan Gregg <firstname.lastname@example.org>, Jann Horn <email@example.com>, Matthew Garrett <firstname.lastname@example.org>, Christian Brauner <email@example.com>, Florent Revest <firstname.lastname@example.org>, Brendan Jackman <email@example.com>, Martin KaFai Lau <firstname.lastname@example.org>, Song Liu <email@example.com>, Yonghong Song <firstname.lastname@example.org>, "Serge E. Hallyn" <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, Nicolas Ferre <firstname.lastname@example.org>, Stanislav Fomichev <email@example.com>, Quentin Monnet <firstname.lastname@example.org>, Andrey Ignatov <email@example.com>, Joe Stringer <firstname.lastname@example.org> Subject: Re: [PATCH bpf-next v4 0/8] MAC and Audit policy using eBPF (KRSI) Date: Thu, 27 Feb 2020 12:40:58 -0600 Message-ID: <20200227184058.GA25392@wind.enjellic.com> (raw) In-Reply-To: <email@example.com> On Thu, Feb 20, 2020 at 06:52:42PM +0100, KP Singh wrote: Good morning, I hope the week is going well for everyone. Apologies for being somewhat late with these comments, I've been recovering from travel. > # 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 allows BPF programs to be attached to LSM hooks 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. On the remote possibility that our practical experiences are relevant to this, I thought I would pitch these comments in, since I see that LWN is covering the issues and sensitivities surrounding BPF based 'intelligent' LSM hooks, if I can take the liberty of referring to them as that. We namespaced a modified version of the Linux IMA implementation in order to provide a mechanism for deterministic system modeling, in order to support autonomously self defensive platforms for IOT/INED/SCADA type applications. Big picture, the objective was to provide 'dynamic intelligence' for LSM decisions, presumably an objective similar to the KRSI initiative. Our IMA implementation, if you can still call it that, pushes actor/subject interaction identities up into an SGX enclave that runs a modeling engine that makes decisions on whether or not a process is engaging in activity inconsistent with a behavioral map defined by the platform or container developer. If the behavior is extra-dimensional (untrusted), the enclave, via an OCALL, sets the value of a 'bad actor' variable in the task control structure that is used to indicate that the context of execution has questionable trust status. We paired this with a very simple LSM that has each hook check a bit position in the bad actor variable/bitfield to determine whether or not the hook should operate on the requested action. Separate LSM infrastructure is provided that specifies whether or not the behavior should be EPERM'ed or logged. An LSM using this infrastructure also has the ability, if triggered by the trust status of the context of execution, to make further assessments based on what information is supplied via the hook itself. Our field experience and testing has suggested that this architecture has considerable utility. In this model, numerous and disparate sections of the kernel can have input into the trust status of a context of execution. This methodology would seem to be consistent with having multiple eBPF tap points in the kernel that can make decisions on what they perceive to be security relevant issues and if and how the behavior should be acted upon by the LSM. At the LSM level the costs are minimal, essentially a conditional check for non-zero status. Performance costs will be with the eBPF code installed at introspection points. At the end of the day. security costs money, if no one is willing to pay the bill we simply won't have secure systems, the fundamental tenant of the inherent economic barrier to security. Food for thought if anyone is interested. Best wishes for a productive remainder of the week. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker IDfusion, LLC SGX secured infrastructure and 4206 N. 19th Ave. autonomously self-defensive platforms. Fargo, ND 58102 PH: 701-281-1686 EMAIL: firstname.lastname@example.org ------------------------------------------------------------------------------ "We have to grow some roots before we can even think about having any blossoms." -- Terrance George Wieland Resurrection.
prev parent reply index Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-20 17:52 KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 1/8] bpf: Introduce BPF_PROG_TYPE_LSM KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 2/8] security: Refactor declaration of LSM hooks KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 3/8] bpf: lsm: provide attachment points for BPF LSM programs KP Singh 2020-02-21 2:25 ` Alexei Starovoitov 2020-02-21 11:47 ` KP Singh [not found] ` <email@example.com> 2020-02-21 11:44 ` KP Singh 2020-02-21 18:23 ` Casey Schaufler [not found] ` <202002211946.A23A987@keescook> 2020-02-23 22:08 ` Alexei Starovoitov 2020-02-24 16:32 ` Casey Schaufler 2020-02-24 17:13 ` KP Singh 2020-02-24 18:45 ` Casey Schaufler 2020-02-24 21:41 ` Kees Cook 2020-02-24 22:29 ` Casey Schaufler 2020-02-25 5:41 ` Alexei Starovoitov 2020-02-25 15:31 ` Kees Cook 2020-02-25 19:31 ` KP Singh 2020-02-26 0:30 ` Casey Schaufler 2020-02-26 5:15 ` KP Singh 2020-02-26 15:35 ` Casey Schaufler 2020-02-25 19:29 ` KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 4/8] bpf: lsm: Add support for enabling/disabling BPF hooks KP Singh 2020-02-21 18:57 ` Casey Schaufler 2020-02-21 19:11 ` James Morris 2020-02-22 4:26 ` Kees Cook 2020-02-20 17:52 ` [PATCH bpf-next v4 5/8] bpf: lsm: Implement attach, detach and execution KP Singh 2020-02-21 2:17 ` Alexei Starovoitov 2020-02-21 12:02 ` KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 6/8] tools/libbpf: Add support for BPF_PROG_TYPE_LSM KP Singh 2020-02-25 6:45 ` Andrii Nakryiko 2020-02-20 17:52 ` [PATCH bpf-next v4 7/8] bpf: lsm: Add selftests " KP Singh 2020-02-20 17:52 ` [PATCH bpf-next v4 8/8] bpf: lsm: Add Documentation KP Singh 2020-02-21 19:19 ` [PATCH bpf-next v4 0/8] MAC and Audit policy using eBPF (KRSI) Casey Schaufler 2020-02-21 19:41 ` KP Singh 2020-02-21 22:31 ` Casey Schaufler 2020-02-21 23:09 ` KP Singh 2020-02-21 23:49 ` Casey Schaufler 2020-02-22 0:22 ` Kees Cook 2020-02-22 1:04 ` Casey Schaufler 2020-02-22 3:36 ` Kees Cook 2020-02-27 18:40 ` Dr. Greg [this message]
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=20200227184058.GA25392@wind.enjellic.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
BPF Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/bpf/0 bpf/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 bpf bpf/ https://lore.kernel.org/bpf \ email@example.com public-inbox-index bpf Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.bpf AGPL code for this site: git clone https://public-inbox.org/public-inbox.git