On Fri, Apr 14, 2023 at 1:24 PM Dr. Greg <greg@xxxxxxxxxxxx> 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@xxxxxxxxxx> 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.
