Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > On Mon, Jun 12, 2023 at 3:49 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >> > On Fri, Jun 9, 2023 at 2:21 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> >> >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >> >> >> > 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. >> >> >> >> No, but every other fd-based mechanism is limited in scope. E.g., if you >> >> pass a map fd that's one specific map that can be passed around, with a >> >> token it's all operations (of a specific type) which is way broader. >> > >> > It's not black and white. Once you have a BPF program FD, you can >> > attach it many times, for example, and cause regressions. Sure, here >> > we are talking about creating multiple BPF maps or loading multiple >> > BPF programs, so it's wider in scope, but still, it's not that >> > fundamentally different. >> >> Right, but the difference is that a single BPF program is a known >> entity, so even if the application you pass the fd to can attach it >> multiple times, it can't make it do new things (e.g., bpf_probe_read() >> stuff it is not supposed to). Whereas with bpf_token you have no such >> guarantee. > > Sure, I'm not claiming BPF token is just like passing BPF program FD > around. My point is that anything in the kernel that is representable > by FD can be passed around to an unintended process through > SCM_RIGHTS. And if you want to have tighter control over who's passing > what, you'd probably need LSM. But it's not a requirement. > > With BPF token it is important to trust the application you are > passing BPF token to. This is not a mechanism to just freely pass > around the ability to do BPF. You do it only to applications you > control. Trust is not binary, though. "Do I trust this application to perform this specific action" is different from "do I trust this application to perform any action in the future". A security mechanism should grant the minimum required privileges required to perform the operation; this token thing encourages (defaults to) broader grants, which is worrysome. > With user namespaces, if we could grant CAP_BPF and co to use BPF, > we'd do that. But we can't. BPF token at least gives us this > opportunity. If the use case is to punch holes in the user namespace isolation I feel like that is better solved at the user namespace level than the BPF subsystem level... -Toke (Ran out of time and I'm about to leave for PTO, so dropping the RPC discussion for now)
