Having a single signature doesn't mean you can't make your scheme work: the signature could be over an array of two hashes, one for the program and one for the map, meaning that the signature could be verified and the hashes extracted, which could then be verified at different points in the execution and verification flow: say verify the program hash immediately but do the map hash after you're sure it can't be modified. > 3. To signing the attachment points, you replied > > > That statement is quite questionable. Yes, IIRC you brought that > > up. And again, runtime policy enforcement has nothing to do with > > proving code provenance. They are completely independent concerns. > > The place where the BPF program is attached is a key part of the > provenance of the BPF program and its security (and other) effects > can vary greatly based on that. (e.g. imagine a reject all LSM > program that is attached to the wrong LSM hook). This is why it's not > the same as module loading. I don't believe anyone's disputing this. However, there is a difference between provenance and policy. Signatures are just about provenance. You proposed adding a policy language to signing at LPC in 2022 and I believe this could be done incrementally to the current patch set. One possible stepping stone to this is to add signatures now and policy later but if you want the attach point also covered now, how about adding an optional third hash over attach_btf_id and the fd; if the hash is present it binds the attach point and if it isn't the skeleton can attach arbitrarily? > 4. > https://lore.kernel.org/bpf/CAADnVQKF+B_YYwOCFsPBbrTBGKe4b22WVJFb8C0PHGmRAjbusQ@xxxxxxxxxxxxxx/ > > Programs can still access maps, now if you combine the issue of > ELF-less loaders and that maps are writeable from other programs as > freezing only affects userspace (i.e. when a binary gets an FD to a > map and tries to modify it with syscalls) your implementation fails. In a world of trusted BPF, I think you can get to some confidence that an attacker can't simply insert an arbitrary BPF program to do this and nor could they get into ring0 without compromising the kernel, so map freezing provides a reasonable measure of safety. It's not perfect, but it's good enough. > The reply there about trusted user-space still needs to come with > better guarantees from the kernel, and the kernel can indeed give > better guarantees, which we will share. The reason for this is that > your trusted binary is not immune to attacks, and once an attacker > gains code execution as this trusted binary, there is no containing > the compromise. This is whitelisting systemd again? I think as a temporary measure until systemd gets on-board with BPF signing, a config parameter is not unreasonable. I also get the impression that there might be a disagreement over scope: what seems to be coming out of BPF is that every signing problem and scenario must be solved before signing can be considered acceptable; however, I think it's not unreasonable to attempt to cover a portion of the use cases and allow for future additions of things like policy so we can get some forward motion to allow others to play with it and produce patches based on their use cases. Regards, James
