Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI)

[Stephen Smalley]

On 1/8/20 1:58 PM, James Morris wrote:
> On Wed, 8 Jan 2020, Stephen Smalley wrote:
>
> > This appears to impose a very different standard to this eBPF-based LSM than
> > has been applied to the existing LSMs, e.g. we are required to preserve
> > SELinux policy compatibility all the way back to Linux 2.6.0 such that new
> > kernel with old policy does not break userspace.  If that standard isn't being
> > applied to the eBPF-based LSM, it seems to inhibit its use in major Linux
> > distros, since otherwise users will in fact start experiencing breakage on the
> > first such incompatible change.  Not arguing for or against, just trying to
> > make sure I understand correctly...
>
> A different standard would be applied here vs. a standard LSM like
> SELinux, which are retrofitted access control systems.
>
> I see KRSI as being more of a debugging / analytical API, rather than an
> access control system. You could of course build such a system with KRSI
> but it would need to provide a layer of abstraction for general purpose
> users.
>
> So yes this would be a special case, as its real value is in being a
> special case, i.e. dynamic security telemetry.

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.

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.  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...