[PATCH v2 bpf-next 00/18] BPF token

[Andrii Nakryiko]

On Wed, Jun 14, 2023 at 5:12 AM Toke Høiland-Jørgensen <toke at redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko at gmail.com> writes:
>
> > On Mon, Jun 12, 2023 at 3:49 AM Toke Høiland-Jørgensen <toke at kernel.org> wrote:
> >>
> >> Andrii Nakryiko <andrii.nakryiko at gmail.com> writes:
> >>
> >> > On Fri, Jun 9, 2023 at 2:21 PM Toke Høiland-Jørgensen <toke at kernel.org> wrote:
> >> >>
> >> >> Andrii Nakryiko <andrii.nakryiko at gmail.com> writes:
> >> >>
> >> >> > On Fri, Jun 9, 2023 at 4:17 AM Toke Høiland-Jørgensen <toke at kernel.org> wrote:
> >> >> >>
> >> >> >> Andrii Nakryiko <andrii at kernel.org> 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)
>