On Mon, Mar 26, 2018 at 2:04 PM, Casey Schaufler [off-list ref] wrote:

On 3/26/2018 1:24 PM, Sargun Dhillon wrote:

quoted

On Mon, Mar 26, 2018 at 1:17 PM, Igor Stoppa [off-list ref] wrote:

quoted

On 26/03/18 22:24, Sargun Dhillon wrote:

quoted

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.

[...]

quoted

      /*
       * 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.

quoted

 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?

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