linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: James Morris <jmorris@namei.org>
Cc: "Kees Cook" <keescook@chromium.org>,
	"KP Singh" <kpsingh@chromium.org>,
	"Casey Schaufler" <casey@schaufler-ca.com>,
	"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>,
	"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>,
	"Paul Moore" <paul@paul-moore.com>
Subject: Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI)
Date: Thu, 9 Jan 2020 13:58:58 -0500	[thread overview]
Message-ID: <e90e03e3-b92f-6e1a-132f-1b648d9d2139@tycho.nsa.gov> (raw)
In-Reply-To: <alpine.LRH.2.21.2001100437550.21515@namei.org>

On 1/9/20 1:11 PM, James Morris wrote:
> On Wed, 8 Jan 2020, Stephen Smalley wrote:
> 
>> The cover letter subject line and the Kconfig help text refer to it as a
>> BPF-based "MAC and Audit policy".  It has an enforce config option that
>> enables the bpf programs to deny access, providing access control. IIRC, in
>> the earlier discussion threads, the BPF maintainers suggested that Smack and
>> other LSMs could be entirely re-implemented via it in the future, and that
>> such an implementation would be more optimal.
> 
> In this case, the eBPF code is similar to a kernel module, rather than a
> loadable policy file.  It's a loadable mechanism, rather than a policy, in
> my view.

I thought you frowned on dynamically loadable LSMs for both security and 
correctness reasons? And a traditional security module would necessarily 
fall under GPL; is the eBPF code required to be likewise?  If not, KRSI 
is a gateway for proprietary LSMs...

> This would be similar to the difference between iptables rules and
> loadable eBPF networking code.  I'd be interested to know how the
> eBPF networking scenarios are handled wrt kernel ABI.
> 
> 
>> Again, not arguing for or against, but wondering if people fully understand
>> the implications.  If it ends up being useful, people will build access
>> control systems with it, and it directly exposes a lot of kernel internals to
>> userspace.  There was a lot of concern originally about the LSM hook interface
>> becoming a stable ABI and/or about it being misused.  Exposing that interface
>> along with every kernel data structure exposed through it to userspace seems
>> like a major leap.
> 
> Agreed this is a leap, although I'm not sure I'd characterize it as
> exposure to userspace -- it allows dynamic extension of the LSM API from
> userland, but the code is executed in the kernel.
> 
> KP: One thing I'd like to understand better is the attack surface
> introduced by this.  IIUC, the BTF fields are read only, so the eBPF code
> should not be able to modify any LSM parameters, correct?
> 
> 
>>   Even if the mainline kernel doesn't worry about any kind
>> of stable interface guarantees for it, the distros might be forced to provide
>> some kABI guarantees for it to appease ISVs and users...
> 
> How is this handled currently for other eBPF use-cases?
> 


  parent reply	other threads:[~2020-01-09 18:58 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 15:41 [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI) KP Singh
2019-12-20 15:41 ` [PATCH bpf-next v1 01/13] bpf: Refactor BPF_EVENT context macros to its own header KP Singh
2019-12-20 20:10   ` Andrii Nakryiko
2019-12-20 20:26     ` KP Singh
2019-12-20 15:41 ` [PATCH bpf-next v1 02/13] bpf: lsm: Add a skeleton and config options KP Singh
2020-01-07 21:13   ` James Morris
2019-12-20 15:41 ` [PATCH bpf-next v1 03/13] bpf: lsm: Introduce types for eBPF based LSM KP Singh
2019-12-20 15:41 ` [PATCH bpf-next v1 04/13] bpf: lsm: Allow btf_id based attachment for LSM hooks KP Singh
2019-12-23 23:54   ` Andrii Nakryiko
2019-12-30 19:22     ` KP Singh
2019-12-20 15:42 ` [PATCH bpf-next v1 05/13] tools/libbpf: Add support in libbpf for BPF_PROG_TYPE_LSM KP Singh
2019-12-24  0:07   ` Andrii Nakryiko
2019-12-24  0:09     ` Andrii Nakryiko
2020-01-03 23:59     ` KP Singh
2019-12-20 15:42 ` [PATCH bpf-next v1 06/13] bpf: lsm: Init Hooks and create files in securityfs KP Singh
2019-12-24  6:28   ` Andrii Nakryiko
2019-12-30 15:37     ` KP Singh
2019-12-30 18:52       ` Andrii Nakryiko
2019-12-30 19:20       ` Kees Cook
2020-01-03 23:53         ` KP Singh
2020-01-07 21:22   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 07/13] bpf: lsm: Implement attach, detach and execution KP Singh
2019-12-24  5:48   ` Andrii Nakryiko
2020-01-07 21:27   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 08/13] bpf: lsm: Show attached program names in hook read handler KP Singh
2020-01-07 21:28   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 09/13] bpf: lsm: Add a helper function bpf_lsm_event_output KP Singh
2019-12-24  6:36   ` Andrii Nakryiko
2019-12-30 15:11     ` KP Singh
2019-12-30 18:56       ` Andrii Nakryiko
2019-12-20 15:42 ` [PATCH bpf-next v1 10/13] bpf: lsm: Handle attachment of the same program KP Singh
2019-12-24  6:38   ` Andrii Nakryiko
2020-01-08 18:21   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 11/13] tools/libbpf: Add bpf_program__attach_lsm KP Singh
2019-12-24  6:44   ` Andrii Nakryiko
2020-01-08 18:24   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 12/13] bpf: lsm: Add selftests for BPF_PROG_TYPE_LSM KP Singh
2019-12-24  6:49   ` Andrii Nakryiko
2020-01-04  0:09     ` KP Singh
2020-01-09 17:59       ` Andrii Nakryiko
2020-01-08 18:25   ` James Morris
2019-12-20 15:42 ` [PATCH bpf-next v1 13/13] bpf: lsm: Add Documentation KP Singh
2019-12-20 17:17 ` [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI) Casey Schaufler
2019-12-20 17:38   ` KP Singh
2019-12-30 19:15     ` Kees Cook
2020-01-08 15:25       ` Stephen Smalley
2020-01-08 18:58         ` James Morris
2020-01-08 19:33           ` Stephen Smalley
2020-01-09 18:11             ` James Morris
2020-01-09 18:23               ` Greg Kroah-Hartman
2020-01-09 18:58               ` Stephen Smalley [this message]
2020-01-09 19:07                 ` James Morris
2020-01-09 19:43                   ` KP Singh
2020-01-09 19:47                     ` Stephen Smalley
2020-01-10 15:27                       ` KP Singh
2020-01-10 17:48                         ` James Morris
2020-01-10 17:53                         ` Alexei Starovoitov
2020-01-14 16:54                           ` Stephen Smalley
2020-01-14 17:42                             ` Stephen Smalley
2020-01-15  2:48                               ` Alexei Starovoitov
2020-01-15 13:59                                 ` Stephen Smalley
2020-01-15 14:09                                   ` Greg Kroah-Hartman
2020-01-15 22:23                                     ` Alexei Starovoitov
2020-01-09 19:11               ` KP Singh
2020-01-08 18:27       ` James Morris
2019-12-20 22:46 ` Mickaël Salaün
2019-12-30 19:30   ` Kees Cook
2019-12-31 12:11     ` Mickaël Salaün
2019-12-22  1:27 ` Alexei Starovoitov
2019-12-30 14:58   ` KP Singh
2019-12-30 19:14     ` Andrii Nakryiko
2019-12-24  6:51 ` Andrii Nakryiko
2019-12-30 15:04   ` KP Singh
2019-12-30 18:58     ` Andrii Nakryiko

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=e90e03e3-b92f-6e1a-132f-1b648d9d2139@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brendan.d.gregg@gmail.com \
    --cc=casey@schaufler-ca.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=paul@paul-moore.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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).