On 3/26/2018 2:51 PM, Sargun Dhillon wrote:

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

quoted

On 3/26/2018 2:10 PM, Sargun Dhillon wrote:

quoted

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

quoted

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?

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.

quoted

quoted

        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?

You can always add ifdefs and unnatural runtime options during development.
You don't need infrastructure support for that. I will grant you minor LSMs
that don't allocate and/or manage data. As you included in your patchset,
you have to identify if a module is "mutable" for this to be a safe feature.
My recollection from the early days of LSM that there were objections to
unloadable modules for other reasons, but that was long ago and I don't
recall them clearly.

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