[RFC 0/3] Safe, dynamically (un)loadable LSMs

[igor.stoppa@huawei.com (Igor Stoppa)]

On 30/11/17 04:28, Casey Schaufler wrote:
> On 11/26/2017 2:15 PM, Sargun Dhillon wrote:
>> This patchset introduces safe dynamic LSM support. It does this via
>> SRCU-protected security hooks. It also EXPORT_SYMBOL_GPLs the symbols
>> required to perform runtime loading, and unloading. The patchset is
>> meant to introduce as little overhead as possible when not used.
>> Additionally, the functionality is disabled by default.
> 
> Can you explain the value in being able to unload a security module?
> I can see having a throttle on an active module, but what do you gain
> by being able to unload it? Can it possibly be worth the inevitable
> memory leaks and almost certain dangling pointers? The restrictions on
> a security module that can work safely in this environment are significant.
> I don't see any point in unloading a module that could work with those
> restrictions. The overhead of making it unloadable is likely to exceed
> the overhead of running it.

There is also another aspect: a readily available "unload" functionality
means that if an attacker is capable of modifying some function pointer,
the unload capability provides an easier way to get rid of the module,
compared to having to poke into memory (like it typically happens when
disabling SELinux, where the attacker flips one of the various state
variables that allow to control how strict it is).

Unload capability might be useful during development, but I am not
really sure it would be a good idea in a production system.

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