On Wed, May 14, 2025 at 2:48 PM KP Singh <kpsi...@kernel.org> wrote: > On Wed, May 14, 2025 at 5:06 AM Paul Moore <p...@paul-moore.com> wrote: > > On Sat, May 10, 2025 at 10:01 PM KP Singh <kpsi...@kernel.org> wrote: > > > > > > > ... > > > > > The signature check in the verifier (during BPF_PROG_LOAD): > > > > > > verify_pkcs7_signature(prog->aux->sha, sizeof(prog->aux->sha), > > > sig_from_bpf_attr, …); > > > > I think we still need to clarify the authorization aspect of your > > proposed design. > > > > Working under the assumption that the core BPF kernel code doesn't > > want to enforce any restrictions, or at least as few as possible ... > > The assumption is not true, I should have clarified it in the original > design. With the UAPI / bpf_attr the bpf syscall is simply denied if > the signature does not verify, so we don't need any LSM logic for > this. There is really no point in continuing as signature verification > is a part of the API contract when the user passes the sig, keyring in > the bpf syscall.
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? * 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? -- paul-moore.com
