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

[Sargun Dhillon]

On Wed, Dec 6, 2017 at 4:00 PM, James Morris <james.l.morris at oracle.com> wrote:
> On Wed, 6 Dec 2017, Sargun Dhillon wrote:
>
>> Should I respin this patch sans module unloading? Still a set of dynamic
>> hooks that are independent to allow for sealable memory support.
>
> Yes, please.
>
>> I'm also wondering what people think of the fs change? I don't think
>> that it makes a lot of sense just having one giant list. I was thinking
>> it might make more sense using the module_name instead.
>
> I don't know how useful this will be in practice.  Who/what will be
> looking at these entries and why?
For the same reason you look at iptables -L -n -- to figure out what's
being invoked,
and what's causing rejections (or falsely accepting requests). In addition,
this is for minor LSMs, so the traditional /sys/kernel/security/lsm doesn't make
a lot of sense in my opinion, as it's not broken out per-hook. Given
that this can
be registered per-hook, versus globally, I think that breaking out the LSMs per
hook makes more sense.

It also can be used to determine if a hook was loaded after boot, if the global
invocations is greater than the invocations of the instance of that hook.

>
>
> --
> James Morris
> <james.l.morris at oracle.com>
>
--
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