On Fri, Jun 9, 2023 at 4:17 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii@xxxxxxxxxx> writes: > > > This patch set introduces new BPF object, BPF token, which allows to delegate > > a subset of BPF functionality from privileged system-wide daemon (e.g., > > systemd or any other container manager) to a *trusted* unprivileged > > application. Trust is the key here. This functionality is not about allowing > > unconditional unprivileged BPF usage. Establishing trust, though, is > > completely up to the discretion of respective privileged application that > > would create a BPF token. > > I am not convinced that this token-based approach is a good way to solve > this: having the delegation mechanism be one where you can basically > only grant a perpetual delegation with no way to retract it, no way to > check what exactly it's being used for, and that is transitive (can be > passed on to others with no restrictions) seems like a recipe for > disaster. I believe this was basically the point Casey was making as > well in response to v1. Most of this can be added, if we really need to. Ability to revoke BPF token is easy to implement (though of course it will apply only for subsequent operations). We can allocate ID for BPF token just like we do for BPF prog/map/link and let tools iterate and fetch information about it. As for controlling who's passing what and where, I don't think the situation is different for any other FD-based mechanism. You might as well create a BPF map/prog/link, pass it through SCM_RIGHTS or BPF FS, and that application can keep doing the same to other processes. Ultimately, currently we have root permissions for applications that need BPF. That's already very dangerous. But just because something might be misused or abused doesn't prevent us from making a good practical use of it, right? Also, there is LSM on top of all of this to override and control how the BPF subsystem is used, regardless of BPF token. It can override any of the privileges mechanism, capabilities, BPF token, whatnot. > > If the goal is to enable a privileged application (such as a container > manager) to grant another unprivileged application the permission to > perform certain bpf() operations, why not just proxy the operations > themselves over some RPC mechanism? That way the granting application It's explicitly what we *do not* want to do, as it is a major problem and logistical complication. Every single application will have to be rewritten to use such a special daemon/service and its API, which is completely different from bpf() syscall API. It invalidates the use of all the libbpf (and other bpf libraries') APIs, BPF skeleton is incompatible with this. It's a nightmare. I've got feedback from people in another company that do have BPF service with just a tiny subset of BPF functionality delegated to such service, and it's a pain and definitely not a preferred way to do things. Just think about having to mirror a big chunk of bpf() syscall as an RPC. So no, BPF proxy is definitely not a good solution. > can perform authentication checks on every operation and ensure its > origins are sound at the time it is being made. Instead of just writing > a blank check (in the form of a token) and hoping the receiver of it is > not compromised... All this could and should be done through LSM in much more decoupled and transparent (to application) way. BPF token doesn't prevent this. It actually helps with this, because organizations can actually dictate that operations that do not provide BPF token are automatically rejected, and those that do provide BPF token can be further checked and granted or rejected based on specific BPF token instance. > > -Toke
