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

[Casey Schaufler]

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:

	if (!gonkulator_enabled)
		return appropriately;

and provide mechanism for flipping the switch.

--
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