On 4/12/2023 11:06 AM, Paul Moore wrote: > On Wed, Apr 12, 2023 at 1:47 PM Kees Cook <keescook@xxxxxxxxxxxx> 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@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. 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
