On Wed, Jun 14, 2023 at 5:12 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > 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. BPF token defaults to not allowing anything, unless you explicitly allow commands/progs/maps. If you don't set allow_cmds, you literally get a useless BPF token that grants you nothing. > > > 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) >
