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

[Andrii Nakryiko]

On Fri, Apr 14, 2023 at 1:24 PM Dr. Greg <greg at enjellic.com> wrote:
>
> On Wed, Apr 12, 2023 at 10:47:13AM -0700, Kees Cook wrote:
>
> Hi, I hope the week is ending well for everyone.
>
> > 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.
>
> > 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).
> >
> > The reason CAP_BPF was created was because there was nothing else that
> > would be fine-grained enough at the time.
>
> This was one of the issues, among others, that the TSEM LSM we are
> working to upstream, was designed to address and may be an avenue
> forward.
>
> TSEM, being narratival rather than deontologically based, provides a
> framework for security permissions that are based on a
> characterization of the event itself.  So the permissions are as
> variable as the contents of whatever BPF related information is passed
> to the bpf* LSM hooks [1].
>
> Currently, the tsem_bpf_* hooks are generically modeled.  We would
> certainly entertain any discussion or suggestions as to what elements
> of the structures passed to the hooks would be useful with respect
> to establishing security policies useful and appropriate to the BPF
> community.

Could you please provide some links to get a bit more context and
information? I'd like to understand at least "narratival rather than
deontologically based" part of this.

>
> We don't want to get in the middle of the restrictive
> vs. authoritative debate, but it would seem that the jury is
> conclusively in on that issue and LSM hooks are not going to be
> allowed to dismiss, or modify, any other security controls.
>
> Hopefully the BPF ABI isn't tied to CAP_BPF as that would seem to make
> it problematic to make controls more granular.
>
> > Kees Cook
>
> Have a good weekend.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
>
> [1]: Plus developers don't need to write security policies, you test
> your application in order to get the desired controls for a workload.