linux-kernel - Re: LSM conversion to static interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Xine.LNX.4.64.0710200631290.4442@us.intercode.com.au>
Date:	Sat, 20 Oct 2007 07:07:53 +1000 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Andreas Gruenbacher <agruen@...e.de>
cc:	linux-kernel@...r.kernel.org
Subject: Re: LSM conversion to static interface

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@...ei.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/