On Wed, Aug 13, 2025 at 6:17 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Wed, Aug 13, 2025 at 5:37 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > > On Wed, Aug 13, 2025 at 11:02 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > It's nice to see a v3 revision, but it would be good to see some > > > comments on Blaise's reply to your v2 revision. From what I can see > > > it should enable the different use cases and requirements that have > > > been posted. > > > > I will defer to Alexei and others here (mostly due to time crunch). It > > would however be useful to explain the use-cases in which signed maps > > are useful (beyond being a different approach than the current > > delegated verification). I wanted to bring this up again as it has been another week with no comment from the BPF side of the house regarding Blaise's additions. As a reminder, Blaise's patch can be found here: https://lore.kernel.org/linux-security-module/87sei58vy3.fsf@xxxxxxxxxxxxx > The use cases and requirements have been described quite a bit in > previous threads already, with both you and Alexei participating in > those discussions. If you really can't find the threads on lore let > me know and I'll be happy to send you links to all of the various > threads from the past several months. > > However, if I had to point to a single email that I felt best > summarized my requirements, I think it might be this: > > <<< QUOTE >>> > The loader (+ implicit loader verification of maps w/original program) > signature verification scheme has been requested by Alexei/KP, and > that's fine, the code is trivial and if the user/admin is satisfied > with that as a solution, great. However, the loader + map signature > verification scheme has some advantages and helps satisfy some > requirements that are not satisfied by only verifying the loader and > relying on the loader to verify the original program stored in the > maps. One obvious advantage is that the lskel loader is much simpler > in this case as it doesn't need to worry about verification of the > program maps as that has already been done in bpf_check_signature(). > I'm sure there are probably some other obvious reasons, but beyond the > one mentioned above, the other advantages that I'm interested in are a > little less obvious, or at least I haven't seen them brought up yet. > As I mentioned in an earlier thread, it's important to have the LSM > hook that handles authorization of a BPF program load *after* the BPF > program's signature has been verified. This is not simply because the > LSM implementation might want to enforce and access control on a BPF > program load due to the signature state (signature verified vs no > signature), but also because the LSM might want to measure system > state and/or provide a record of the operation. If we only verify the > lskel loader, at the point in time that the security_bpf_prog_load() > hook is called, we haven't properly verified both the loader and the > original BPF program stored in the map, that doesn't happen until much > later when the lskel loader executes. Yes, I understand that may > sound very pedantic and fussy, but there are users who care very much > about those details, and if they see an event in the logs that > indicates that the BPF program signature has been verified as "good", > they need that log event to be fully, 100% true, and not have an > asterix of "only the lskel loader has been verified, the original BPF > program will potentially be verified later without any additional > events being logged to indicate the verification". > <<< /QUOTE >>> > > The above was taken from this on-list email: > https://lore.kernel.org/linux-security-module/CAHC9VhQT=ymqssa9ymXtvssHTdVH_64T8Mpb0Mh8oxRD0Guo_Q@xxxxxxxxxxxxxx/ -- paul-moore.com
