[PATCH bpf-next v10 5/5] bpf: Only enable BPF LSM hooks when an LSM program is attached
Casey Schaufler
casey at schaufler-ca.com
Wed May 15 16:57:50 UTC 2024
On 5/15/2024 9:44 AM, KP Singh wrote:
>
>> 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?
I think the bike shed should be painted blue.
Sorry. Seriously, I like LSM_HOOK_RUNTIME.
More information about the Linux-security-module-archive
mailing list