On Sat, May 17, 2025 at 10:49 PM Paul Moore <p...@paul-moore.com> wrote: > > On May 17, 2025 12:13:50 PM Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > 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. > > It would be good for you to explain how the existing LSM hook is sufficient > to authorize the loading of a BPF program using the signature validation > state determined in the BPF verifier.
I already explained: .. a job of trivial LSM: if (prog_attr doesn't have signature && (task == .. || task is under certain cgroup || whatever)) disallow. If that's not obvious you have to wait for patches.
