[RFC PATCH 2/2] security: Add mechanism to (un)load LSMs after boot time

[Sargun Dhillon]

On Mon, Mar 26, 2018 at 2:46 PM, Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 3/26/2018 2:10 PM, Sargun Dhillon wrote:
>> On Mon, Mar 26, 2018 at 2:04 PM, Casey Schaufler <casey at schaufler-ca.com> wrote:
>>> On 3/26/2018 1:24 PM, Sargun Dhillon wrote:
>>>> On Mon, Mar 26, 2018 at 1:17 PM, Igor Stoppa <igor.stoppa at huawei.com> wrote:
>>>>> On 26/03/18 22:24, Sargun Dhillon wrote:
>>>>>> This patch introduces a mechanism to add mutable hooks at the end of the
>>>>>> callback chain for each LSM hook. It allows for built-in kernel LSMs
>>>>>> to be unloaded, as well as modular LSMs to be loaded after boot-time.
>>>>>> It also does not compromise the security of hooks which are never
>>>>>> meant to be unloaded.
>>>>> Looking at this from the perspective of really convincing people to use
>>>>> other modules, there is a problem, imho.
>>>>>
>>>>> [...]
>>>>>
>>>>>>       /*
>>>>>>        * Register with LSM
>>>>>>        */
>>>>>> -     security_add_hooks(smack_hooks, ARRAY_SIZE(smack_hooks), "smack");
>>>>>> +     security_add_hooks(smack_hooks, ARRAY_SIZE(smack_hooks), "smack",
>>>>>> +                             false);
>>>>> Hardcoding what is (im)mutable will never satisfy everyone.
>>>>> If, instead, this decision was delegated to the kernel command line, it
>>>>> would be possible to have any module to become immutable -or not-
>>>>> depending on the default values and the configuration received at boot.
>>>>>
>>>>> A distro could ship with its defaults and then any user could
>>>>> reconfigure it, without having to recompile or install anything, just
>>>>> editing the command line.
>>>>>
>>>>> --
>>>>> igor
>>>> Today, the only "mutable" module we have is SELinux.
>>> Paul Moore has threatened to remove the "mutable" option from
>>> SELinux should it bump up high enough on his priority list.
>>> The conditions under which you can disable SELinux are very
>>> limited, you can't unload it after the policy has been loaded.
>>>
>>>>  It has a kernel
>>>> config flag which determines if it is unloadable (mutable) or not. If
>>>> you look at the patchset, it, in fact, sets mutability based on that
>>>> config flag:
>>>>
>>>>
>>>> -       security_add_hooks(selinux_hooks, ARRAY_SIZE(selinux_hooks), "selinux");
>>>> +       security_add_hooks(selinux_hooks, ARRAY_SIZE(selinux_hooks), "selinux",
>>>> +                               IS_ENABLED(CONFIG_SECURITY_SELINUX_DISABLE));
>>>>
>>>> Similarly, modules can change this behaviour based on their own
>>>> choices, whether that be config flags, boot parameters, or similar. In
>>>> my opinion, most LSMs should never be unloadable. In fact, we don't
>>>> really have a safe way (in this patchset) to unload the security
>>>> modules' code safely. Doing this would either require usage of (s)rcu,
>>>> or a similar concurrency control mechanism.
>>> If you can't safely unload the code, what is the point of making
>>> a module unloadable? Start every hook with:
>> s/module/hook/
>> Ask the SELinux folk?
>
> SELinux can safely unload the hooks because they limit the ability
> to unload to a point before they've started allocating data. They
> aren't proud of it. I seriously doubt they'd have if if you could
> run will a NULL policy.
>
>>>         if (!gonkulator_enabled)
>>>                 return appropriately;
>>>
>>> and provide mechanism for flipping the switch.
>>>
>> I intend to eventually follow-up this patch with a way to safely
>> unload the code, but I'd prefer to get (safe) dynamic *hooking* and
>> *unhooking* first, and then later on we can make it so the code can
>> get unloaded.
>
> Unless you want to restrict the unhooking and unloading to a point
> where no data has been allocated by the module it's going to be
> difficult to argue that it's safe to unhook and/or unload a module.
> Sure, SELinux has that restriction, but the use case is a bit
> questionable.
>
>
What's wrong for this in the case of during development, and for minor LSMs?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html