[PATCH] security: convert security hooks to use hlist

Igor Stoppa igor.stoppa at huawei.com
Mon Mar 26 09:18:24 UTC 2018

On 25/03/18 23:02, Sargun Dhillon wrote:
> On Sun, Mar 25, 2018 at 10:12 AM, Casey Schaufler
> <casey at schaufler-ca.com <mailto:casey at schaufler-ca.com>> wrote:
>     On 3/25/2018 3:08 AM, Sargun Dhillon wrote:
>     > This changes security_hook_heads to use hlist_heads instead of
>     > the circular doubly-linked list heads. This should cut down
>     > the size of the struct by about half.
>     My only concern is with the possibility of making
>     security modules dynamically loadable and unloadable.
>     I know that Tetsuo is still hoping to have that, and
>     I have worked to make sure that we don't do anything
>     to preclude it. If he has no objection, I don't either.

I couldn't really object, even if I wanted to :-)
I'm still working to try to get pmalloc accepted, but assuming that it
eventually succeedes, what would be the approach to make the unloading

The idea of pmalloc vs hooks was to write protect the hooks, to avoid
sidestepping any security module, by wiping away its registered handle.

If the hook is write protected, how does the unloading work?

Is it going to be mutually exclusive? Like: write protect for increased
robustness or allow unloading for other cases (ex: development).

Initially I understood that there was an interest in loading *in a later
phase* additional modules, for example as result of modification to the
command line or maybe as result of modprobe from userspace, and then
protecting the whole thing.

But that seems to me very different from unloading.

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

More information about the Linux-security-module-archive mailing list