On Sat, Jun 24, 2023 at 5:28 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > On Sat, Jun 24, 2023, at 6:59 AM, Andy Lutomirski wrote: > > On Fri, Jun 23, 2023, at 4:23 PM, Daniel Borkmann wrote: > > > > > If this series was about passing a “may load kernel modules” token > > around, I think it would get an extremely chilly reception, even though > > we have module signatures. I don’t see anything about BPF that makes > > BPF tokens more reasonable unless a real security model is developed > > first. > > > > To be clear, I'm not saying that there should not be a mechanism to use BPF from a user namespace. I'm saying the mechanism should have explicit access control. It wouldn't need to solve all problems right away, but it should allow incrementally more features to be enabled as the access control solution gets more powerful over time. > > BPF, unlike kernel modules, has a verifier. While it would be a departure from current practice, permission to use BPF could come with an explicit list of allowed functions and allowed hooks. > > (The hooks wouldn't just be a list, presumably -- premission to install an XDP program would be scoped to networks over which one has CAP_NET_ADMIN, presumably. Other hooks would have their own scoping. Attaching to a cgroup should (and maybe already does?) require some kind of permission on the cgroup. Etc.) > > If new, more restrictive functions are needed, they could be added. > This seems to align with BPF fd/token delegation. I asked in another thread if more context/policies could be provided from user space when configuring the fd and the answer: it can be on top as a follow up... The user namespace is just one single use case of many, also confirmed in this reply [0] . Getting it to work in init userns should be the first logical step anyway, then once you have an fd you can delegate it or pass it around to childs that create nested user namespaces, etc as it is currently done within container managers when they setup the environments including the uid mapping... and of course there should be some sort of mechanism to ensure that the delegated fd comes say from a parent user namespace before using it and deny any cross namespaces usage... > Alternatively, people could try a limited form of BPF proxying. It wouldn't need to be a full proxy -- an outside daemon really could approve the attachment of a BPF program, and it could parse the program, examine the list of function it uses and what the proposed attachment is to, and make an educated decision. This would need some API changes (maybe), but it seems eminently doable. > Even a *limited* BPF proxying seems more in the opposite direction of what you are suggesting above? If I have an fd or the bpffs mount with a token properly setup by the manager I can directly use it inside my containers, load small bpf programs without talking to another external API of another container... I assume the manager passed me the rights or already pre-approved the operation... Of course there is also the case of approving the attachment of bpf programs without passing an fd/token which I assume is your point or in other words denying it which makes perfectly sense indeed, then yes: an outside daemon could do this, systemd / container managers etc with the help of LSMs could *deny* attachment of BPF programs without any external API changes (they already support LSMs), IIRC there is already a hook part of bpf() syscall to restrict some program types maybe, so future cases of bpf token should add in kernel and LSMs + bpf-lsm hooks, ensure they are properly called with the full context and restrict further... So for the "limited form of BPF proxying... to approve attachment..." I think with fd delegation of bpffs mount (that requires privileges to set it up) then an in kernel LSM hooks on top to tighten this up is the way to go [0] https://lore.kernel.org/bpf/CAEf4BzbjGBY2=XGmTBWX3Vrgkc7h0FRQMTbB-SeKEf28h6OhAQ@xxxxxxxxxxxxxx/
