Finer-grained BPF tokens

Posted Oct 12, 2023 14:57 UTC (Thu) by bluca (subscriber, #118303)
Parent article: Finer-grained BPF tokens

This appears aimed at solving the problem of "who can run BPF programs", which I imagine matters for certain use cases. However, as the owner of a very locked down system, that is not a very interesting question for me. What stops me from enabling BPF on these systems is an answer to the question of "_which_ BPF programs are allowed to run". Unless I'm missing something, it doesn't seem these patches can address this issue?

to post comments

Finer-grained BPF tokens

Posted Oct 12, 2023 21:42 UTC (Thu) by tohojo (subscriber, #86756) [Link] (2 responses)

No, you are exactly right. Which is why I don't see much value in this approach as a general "security solution" for BPF. It solves exactly one problem: allowing a container workload that uses BPF to be slightly more constrained by using user namespaces with this BPF-specific hole punched in it.

This is fine for environments where the whole software stack is under the control of a single entity (e.g., the hyperscalers who also happen to be who is pushing this). But for a full security solution there also needs to be some constraint on *which* programs can be loaded, as you point out. Sadly no one has come up with a good solution for that so far. Signing (like for kernel modules) doesn't really work well because of the dynamic nature of BPF programs. There have been some attempts to find a way around this, but nothing that's really caught on...

Finer-grained BPF tokens

Posted Oct 12, 2023 22:27 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

Well, my former colleague Matteo had a working and simple patchset that treated precompiled co-re bpf programs like kernel modules: https://lore.kernel.org/bpf/20211203191844.69709-1-mcroce...
Sure, it doesn't help with the jit-compiled ones, but one can conceivably restrict that and be limited to pre-compiled programs only. But it was rejected in favour of a different bpf-native approach, that after 2 years sadly hasn't happened yet.

Finer-grained BPF tokens

Posted Oct 13, 2023 9:48 UTC (Fri) by tohojo (subscriber, #86756) [Link]

Ah yes, now that you mention it, I vaguely remember that discussion. Yeah, sadly nothing comprehensive has materialised yet. I would have liked to have a mechanism that just delegates the policy decisions to userspace (similar to seccomp-notify, but bpf-specific so the kernel can ensure consistency and make sure we avoid TOCTOU races), but that didn't fly with upstream either.

For container deployments we are also experimenting with just doing everything in userspace: https://bpfd.dev/
This uses a "system daemon will load BPF on your behalf" model, and will allow arbitrary verification (including through signatures). But of course it requires you to trust the system daemon, and it precludes some of the dynamic code generation stuff that John was talking about in that thread you linked. So again, tradeoffs...