[PATCH bpf-next v10 5/5] bpf: Only enable BPF LSM hooks when an LSM program is attached

[KP Singh]

> On 15 May 2024, at 10:08, KP Singh <kpsingh at kernel.org> wrote:
> 
> On Fri, May 10, 2024 at 7:23 AM KP Singh <kpsingh at kernel.org> wrote:
>> 
>> 
>> 
>>> On 9 May 2024, at 16:24, Paul Moore <paul at paul-moore.com> wrote:
>>> 
>>> On Wed, May 8, 2024 at 3:00 AM KP Singh <kpsingh at kernel.org> wrote:
>>>> One idea here is that only LSM hooks with default_state = false can be toggled.
>>>> 
>>>> This would also any ROPs that try to abuse this function. Maybe we can call "default_disabled" .toggleable (or dynamic)
>>>> 
>>>> and change the corresponding LSM_INIT_TOGGLEABLE. Kees, Paul, this may be a fair middle ground?
>>> 
>>> Seems reasonable to me, although I think it's worth respinning to get
>>> a proper look at it in context.  Some naming bikeshedding below ...
>>> 
>>>> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>>>> index 4bd1d47bb9dc..5c0918ed6b80 100644
>>>> --- a/include/linux/lsm_hooks.h
>>>> +++ b/include/linux/lsm_hooks.h
>>>> @@ -117,7 +117,7 @@ struct security_hook_list {
>>>>       struct lsm_static_call  *scalls;
>>>>       union security_list_options     hook;
>>>>       const struct lsm_id             *lsmid;
>>>> -       bool                            default_enabled;
>>>> +       bool                            toggleable;
>>>> } __randomize_layout;
>>> 
>>> How about inverting the boolean and using something like 'fixed'
>>> instead of 'toggleable'?
>>> 
>> 
>> I would prefer not changing the all the other LSM_HOOK_INIT calls as we change the default behaviour then. How about calling it "dynamic"
>> 
>> LSM_HOOK_INIT_DYNAMIC and call the boolean dynamic
>> 
> 
> Paul, others, any preferences here?

I will throw another in the mix, LSM_HOOK_RUNTIME which captures the nature nicely. (i.e. these hooks are enabled / disabled at runtime). Thoughts?

> 
> - KP
> 
>> - KP
>> 
>>> --
>>> paul-moore.com