lkml.org 
[lkml]   [2020]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI)
From
Date
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...

\
 
 \ /
  Last update: 2020-01-08 20:34    [W:0.084 / U:2.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site