[PATCH v3 0/4] Introducing Hornet LSM

[Paul Moore]

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