[PATCH v3 0/4] Introducing Hornet LSM
Paul Moore
paul at paul-moore.com
Sun May 18 05:48:57 UTC 2025
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.
--
paul-moore.com
>
More information about the Linux-security-module-archive
mailing list