Re: LSM conversion to static interface

From: James Morris
Date: Fri Oct 19 2007 - 17:08:29 EST


On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:

> Quoting from commit 20510f2f (Convert LSM into a static interface):
> > In a nutshell, there is no safe way to unload an LSM. The modular interface
> > is thus unecessary and broken infrastructure. It is used only by
> > out-of-tree modules, which are often binary-only, illegal, abusive of the
> > API and dangerous, e.g. silently re-vectoring SELinux.
>
> This is idiotic. Just because there is no safe way to unload SELinux
>
> - doesn't mean there is no safe way to unload other LSMs: if nothing
> but that, unloading is handy during development.

Can you provide an example of a real LSM which can be safely unloaded and
also needs to be unloaded?

Why should we maintain infrastructure and extra complexity in the kernel
for theoretical or unknown modules ?

Linus has asked for any valid out of tree users who need a dynamic
interface to step forward. Where are they?

As one of the people who actually maintains LSM (rather than simply
speculates about it), I object to maintaining infrastructure which, to the
best of my knowledge, is only used by out of tree, binary, broken junk.

If you recall, the original motivation for this patch was when the idea
of adding a new capability to control security model unload was raised.

That is, new security infrastructure was being proposed merely to cater to
some other existing unnecessary security infrastructure. So, rather than
doing that, I proposed removing the unnecessary infrastructure.

I agree with Linus: if you can demonstrate a valid, concrete use for
dynamic LSMs, then the infrastructure to support them can easily be
reinstated.

But until then, it seems both reasonable and in keeping with good kernel
development practices, to not maintain unused infrastructure.


- James
--
James Morris
<jmorris@xxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/