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. 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 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... -Toke
