On Mon, May 19, 2025 at 3:20 PM KP Singh <kpsi...@kernel.org> wrote: > > On Sun, May 18, 2025 at 11:34 PM Paul Moore <p...@paul-moore.com> wrote: > > > > On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov > > <alexei.starovoi...@gmail.com> wrote: > > > 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. > > > > I read that earlier reply as an example that covers a sample use case, > > I didn't realize you were asserting that was the only approach you > > were considering. Perhaps that was the source of confusion earlier, > > we may disagree, but I don't intentionally "twist" words; not only is > > that rude, it's just stupid in public, archived discussions. > > > > As I mentioned previously, we really need to see an explicit yes/no > > flag from the BPF verifier to indicate that the signature on the BPF > > program has been validated. It really should be as simple as adding a > > bool to bpf_prog_aux which the BPF verifier sets to true upon > > successful signature validation, and then an LSM can use this flag as > > input to an access control decision in a hook placed after the > > verifier. Are you objecting to the addition of a flag in the > > bpf_prog_aux struct (or some other struct tightly coupled to the BPF > > program), the LSM hook after the verifier, or both? It would also be > > helpful if you can elaborate on the technical reasons behind these > > objections. > > Neither the aux field, nor the hook are required because: > > * If the signature is passed, it will be enforced, there are no > "runtime aspects" that need to be configurable here. > * What the LSM can specify a policy for is when a signature is not > passed, for this, it does not need an aux field or a signature or the > new hook, existing hooks are sufficient. >
What about wanting to create a policy that requires signatures under certain situations and allowing the lack of a signature under others? How is that implemented with the existing hooks? As I understand it, all the existing hooks know (would know) is that _if_ there is a signature _then_ it will be enforced. There is no way to know _whether_ there is a signature. An example policy I can think of is that most users (with CAP_BPF) must submit signed programs but some users are exempted. Would that policy be able to be made with the current hooks? > - KP > > > > > -- > > paul-moore.com >
