[PATCH bpf-next 0/8] New BPF map and BTF security LSM hooks

[Casey Schaufler]

On 4/12/2023 11:06 AM, Paul Moore wrote:
> On Wed, Apr 12, 2023 at 1:47 PM Kees Cook <keescook at chromium.org> wrote:
>> On Wed, Apr 12, 2023 at 12:49:06PM -0400, Paul Moore wrote:
>>> On Wed, Apr 12, 2023 at 12:33 AM Andrii Nakryiko <andrii at kernel.org> wrote:
>>>> Add new LSM hooks, bpf_map_create_security and bpf_btf_load_security, which
>>>> are meant to allow highly-granular LSM-based control over the usage of BPF
>>>> subsytem. Specifically, to control the creation of BPF maps and BTF data
>>>> objects, which are fundamental building blocks of any modern BPF application.
>>>>
>>>> These new hooks are able to override default kernel-side CAP_BPF-based (and
>>>> sometimes CAP_NET_ADMIN-based) permission checks. It is now possible to
>>>> implement LSM policies that could granularly enforce more restrictions on
>>>> a per-BPF map basis (beyond checking coarse CAP_BPF/CAP_NET_ADMIN
>>>> capabilities), but also, importantly, allow to *bypass kernel-side
>>>> enforcement* of CAP_BPF/CAP_NET_ADMIN checks for trusted applications and use
>>>> cases.
>>> One of the hallmarks of the LSM has always been that it is
>>> non-authoritative: it cannot unilaterally grant access, it can only
>>> restrict what would have been otherwise permitted on a traditional
>>> Linux system.  Put another way, a LSM should not undermine the Linux
>>> discretionary access controls, e.g. capabilities.
>>>
>>> If there is a problem with the eBPF capability-based access controls,
>>> that problem needs to be addressed in how the core eBPF code
>>> implements its capability checks, not by modifying the LSM mechanism
>>> to bypass these checks.

Agreed. A lot of thought went into this. The LSM mechanism would be
vastly different if the hooks were authoritative instead of restrictive.

>> I think semantics matter here. I wouldn't view this as _bypassing_
>> capability enforcement: it's just more fine-grained access control.
>>
>> For example, in many places we have things like:
>>
>>         if (!some_check(...) && !capable(...))
>>                 return -EPERM;
>>
>> I would expect this is a similar logic. An operation can succeed if the
>> access control requirement is met. The mismatch we have through-out the
>> kernel is that capability checks aren't strictly done by LSM hooks. And
>> this series conceptually, I think, doesn't violate that -- it's changing
>> the logic of the capability checks, not the LSM (i.e. there no LSM hooks
>> yet here).
> Patch 04/08 creates a new LSM hook, security_bpf_map_create(), which
> when it returns a positive value "bypasses kernel checks".  The patch
> isn't based on either Linus' tree or the LSM tree, I'm guessing it is
> based on a eBPF tree, so I can't say with 100% certainty that it is
> bypassing a capability check, but the description claims that to be
> the case.
>
> Regardless of how you want to spin this, I'm not supportive of a LSM
> hook which allows a LSM to bypass a capability check.  A LSM hook can
> be used to provide additional access control restrictions beyond a
> capability check, but a LSM hook should never be allowed to overrule
> an access denial due to a capability check.
>
>> The reason CAP_BPF was created was because there was nothing else that
>> would be fine-grained enough at the time.

There's nothing stopping you from having a fine grained mechanism that
further restricts a process with CAP_BPF. SELinux implements many checks
that can, policy willing, restrict a process with a capability from doing
what the capability permits.

> The LSM layer predates CAP_BPF, and one could make a very solid
> argument that one of the reasons LSMs exist is to provide
> supplementary controls due to capability-based access controls being a
> poor fit for many modern use cases.
>
> --
> paul-moore.com