[PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

Peter Dolding oiaohm at gmail.com
Thu Apr 5 12:28:30 UTC 2018


On Thu, Apr 5, 2018 at 9:34 PM, Igor Stoppa <igor.stoppa at huawei.com> wrote:
> On 05/04/18 13:31, Peter Dolding wrote:
>> On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa <igor.stoppa at huawei.com> wrote:
>> There is a shade of grey between something being a security hazard and
>> something being a useful feature.
>
> Maybe the problem I see is only in the naming: if what right now is
> addressed as "mutable" were to be called in some other way that does not
> imply that it's impossible to lock it down, then I think there wouldn't
> be much of a problem anymore.
>
> How about s/mutable/protectable/g ?
>
> Then it could be a boot time parameter to decide if the "extra" hooks
> should be protected or stay writable, for example for performing more
> extensive testing.
>
Due to being a shades of grey area I would say kconfig 2 option and 1
boot time parameter.

Some kernels the ability to change LSM on fly should be fully disabled
in the build process.

The abplity to change LSM at runtime has limited valid usage cases so
even if the kernel is built with the ablity to change LSM at runtime
enabled it should still be off by default until enabled with boot time
parameter.   So those who need the feature turn it on and those who
don't need it on cannot turn it on just by installing a kernel.   For
systems that cannot use Linux kernel command line features to turn
stuff on and off a kernel configuration option to change the default
to on with warning in kernel configure.   So 2 kconfig entries and 1
Kernel Boot Parameter.   Of course when a feature like this is enabled
there should be a kernel message so its recorded in logs and is check
able if a feature like this that can lower security is turn on.

The ability to change LSM on fly i see the development usage cases.
I can not think of a single production system usage case for anyone
who is not a developer.   I might be thinking way to narrow.  Unless
someone else can find another use case I would suggest following what
I suggest how a feature like this is enabled.

Naming the feature what ever you think is suitable.

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