On Wed, May 14, 2025 at 2:48 PM KP Singh kpsingh@kernel.org wrote:
On Wed, May 14, 2025 at 5:06 AM Paul Moore paul@paul-moore.com wrote:
On Sat, May 10, 2025 at 10:01 PM KP Singh kpsingh@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?