[PATCH v3 0/4] Introducing Hornet LSM

[Alexei Starovoitov]

On Sat, May 17, 2025 at 10:49 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On May 17, 2025 12:13:50 PM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> > On Sat, May 17, 2025 at 8:03 AM Paul Moore <paul at paul-moore.com> wrote:
> >> On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
> >> <alexei.starovoitov at gmail.com> wrote:
> >>> On Fri, May 16, 2025 at 12:49 PM Paul Moore <paul at 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.