Date:   Fri, 10 Jan 2020 05:11:38 +1100 (AEDT)
From:   James Morris <jmorris@...ei.org>
To:     Stephen Smalley <sds@...ho.nsa.gov>
cc:     Kees Cook <keescook@...omium.org>, KP Singh <kpsingh@...omium.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        open list <linux-kernel@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, linux-security-module@...r.kernel.org,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Thomas Garnier <thgarnie@...omium.org>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Paul Turner <pjt@...gle.com>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        Jann Horn <jannh@...gle.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Christian Brauner <christian@...uner.io>,
        Mickaël Salaün <mic@...ikod.net>,
        Florent Revest <revest@...omium.org>,
        Brendan Jackman <jackmanb@...omium.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Quentin Monnet <quentin.monnet@...ronome.com>,
        Andrey Ignatov <rdna@...com>, Joe Stringer <joe@...d.net.nz>,
        Paul Moore <paul@...l-moore.com>
Subject: Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF
 (KRSI)

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.

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?

-- 
James Morris
<jmorris@...ei.org>

Powered by blists - more mailing lists