On Sat, May 17, 2025 at 8:03 AM Paul Moore <p...@paul-moore.com> wrote: > > On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Fri, May 16, 2025 at 12:49 PM Paul Moore <p...@paul-moore.com> wrote: > > > > > > I think we need some clarification on a few of these details, it would > > > be good if you could answer the questions below about the > > > authorization aspects of your design? > > > > > > * Is the signature validation code in the BPF verifier *always* going > > > to be enforced when a signature is passed in from userspace? In other > > > words, in your design is there going to be either a kernel build time > > > or runtime configuration knob that could selectively enable (or > > > disable) signature verification in the BPF verifier? > > > > If there is a signature in union bpf_attr and it's incorrect > > the prog_load command will be rejected. > > No point in adding a knob to control that. > > I agree that when a signature is provided and that signature check > fails, the BPF load should be rejected. I'm simply trying to > understand how you envision your design handling all of the cases, not > just this one, as well as what build and runtime options you expect > for controlling various aspects of this behavior. > > > > * In the case where the signature validation code in the BPF verifier > > > is active, what happens when a signature is *not* passed in from > > > userspace? Will the BPF verifier allow the program load to take > > > place? Will the load operation be blocked? Will the load operation > > > be subject to a more granular policy, and if so, how do you plan to > > > incorporate that policy decision into the BPF program load path? > > > > If there is no signature the existing loading semantics will remain intact. > > We can discuss whether to add a sysctl or cgroup knob to disallow > > loading when signature is not present ... > > As mentioned earlier this week, if the BPF verifier is performing the > signature verification as KP described, we will need a LSM hook after > the verifier to serve as an access control point. Of course that > doesn't preclude the addition of some type of sysctl/cgroup/whatever > based access control, but the LSM hook would be needed regardless.
No. New hook is not needed. > > but it probably should be a job of trivial LSM ... > > Exactly. If the LSM is simply verifying the signature validation > state of the BPF program being loaded it seems like an addition to IPE > would be the best option from an upstream, in-tree perspective. > However, with the post verifier LSM hook in place, one could also > supply a BPF LSM to do something similar. > > It sounds like we are in agreement on the desirability and need for a > post verifier LSM hook; we'll keep moving forward with this idea > despite KP's earlier objections to the hook. Don't twist my words please. We're absolutely _not_ in agreement. What I described above can be done with the existing hook and its current set of arguments. We're not going to move or change the existing hook.
