"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," explained James Morris in an October 17'th commit message converting LSM to be a static interface. Andreas Gruenbacher countered, "LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM loadable modules have been known to do lots of bad things, and yet nobody made them non-loadable either (yet)." Linus Torvalds explained that he was willing to unmerge the commit if a valid use for unloadable modules was demonstrated, "I repeat: we can undo that commit, but I will damn well not care one whit about yet another pointless security model flamewar."
Jan Engelhardt pointed to his multiadm security framework which provides multiple "root" users each with unique UIDs as an example of an LSM that benefits from supporting loading and unloading modules. "The use case is so that profs (taking the role of sub-admins), can operate on student's data/processes/etc. (quite often needed), but without having the full root privileges," Jan explained, adding, "this LSM basically grants extra rights unlike most other LSMs, which is why modprobe makes much more sense here.(It also does not have to do any security labelling that would require it to be loaded at boot time already.)" James acknowledged, "based on Linus' criteria, this appears to be a case for reverting the static LSM patch."
From: Andreas Gruenbacher
Subject: Re: LSM conversion to static interface
Date: Oct 19, 1:26 pm 2007
On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> >
> > But then I noticed that, while the LSM would remain in existence, it was
> > being closed to out-of-tree security frameworks. Yikes! Since then,
> > I've been following the rush to put SMACK, TOMOYO and AppArmor
> > "in-tree".
>
> Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE
> people were ok with it (AppArmor), but I'm with you - I applied it, but
> I'm also perfectly willing to unapply it if there actually are valid
> out-of-tree users that people push for not merging.
The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.
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.
- doesn't mean that module *loading* is unsafe. The patch removes module
loading as well, which hurts more than removing module unloading.
LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM
loadable modules have been known to do lots of bad things, and yet nobody
made them non-loadable either (yet).
> [...]
> For example, I do kind of see the point that a "real" security model might
> want to be compiled-in, and not something you override from a module.
Non-trivial modules (i.e., practically everything beyond capabilities) become
effective only after loading policy, anyway. If you can load policy, you can
as well first load a security module without making the system insecure.
Thanks,
Andreas
-
From: James Morris
Subject: Re: LSM conversion to static interface
Date: Oct 19, 2:07 pm 2007
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@namei.org>
-
From: Linus Torvalds
Subject: Re: LSM conversion to static interface
Date: Oct 19, 1:40 pm 2007
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>
> Non-trivial modules (i.e., practically everything beyond capabilities) become
> effective only after loading policy, anyway. If you can load policy, you can
> as well first load a security module without making the system insecure.
I'd like to note that I asked people who were actually affected, and had
examples of their real-world use to step forward and explain their use,
and that I explicitly mentioned that this is something we can easily
re-visit.
But I also note that you did no such thing, neither has anybody else.
The fact is, security people *are* insane. You just argue all the time,
instead fo doing anything productive. So please don't include me in the Cc
on your insane arguments - instead do something productive and I'm
interested.
Ok? That was the whole point of LSM in the first place. I'm *not*
interested in getting roped into your insane arguments. I'm interested in
moving forward and having real examples of real use and code. Until then,
this issue is closed. I thought I had made that clear already, but
apparently not clear enough.
So I repeat: we can undo that commit, but I will damn well not care one
whit about yet another pointless security model flamewar.
Linus
-
From: Jan Engelhardt
Subject: Re: LSM conversion to static interface
Date: Oct 20, 4:05 am 2007
On Oct 19 2007 13:40, Linus Torvalds wrote:
>On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>>
>> Non-trivial modules (i.e., practically everything beyond capabilities) become
>> effective only after loading policy, anyway. If you can load policy, you can
>> as well first load a security module without making the system insecure.
>
>I'd like to note that I asked people who were actually affected, and had
>examples of their real-world use to step forward and explain their use,
>and that I explicitly mentioned that this is something we can easily
>re-visit.
>
I do have a pseudo LSM called "multiadm" at
http://freshmeat.net/p/multiadm/ , quoting:
The MultiAdmin security framework kernel module provides a means
to have multiple "root" users with unique UIDs. This bypasses
collation order problems with NSCD, allows you to have files
with unique owners, and allows you to track the quota usage for
every "real" user. It also implements a "sub-admin", a partially
restricted root user who has full read-only access to most
subsystems, but write rights only to a limited subset, for
example writing to files or killing processes only of certain
users.
The use case is so that profs (taking the role of sub-admins), can
operate on student's data/processes/etc. (quite often needed), but
without having the full root privileges.
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM is
basically grants extra rights unlike most other LSMs[1], which is why
modprobe makes much more sense here. (It also does not have to do any
security labelling that would require it to be loaded at boot time
already.)
Does that sound productive?
>The fact is, security people *are* insane. You just argue all the time,
>instead fo doing anything productive. So please don't include me in the Cc
>on your insane arguments - instead do something productive and I'm
>interested.
[1] SELinux: What I remember from coker.com.au's selinux test machine,
everyone had UID 0 and instead had powers revoked.
-
From: James Morris
Subject: Re: LSM conversion to static interface
Date: Oct 20, 3:57 pm 2007
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> >I'd like to note that I asked people who were actually affected, and had
> >examples of their real-world use to step forward and explain their use,
> >and that I explicitly mentioned that this is something we can easily
> >re-visit.
> >
>
> I do have a pseudo LSM called "multiadm" at
> http://freshmeat.net/p/multiadm/ , quoting:
>
Based on Linus' criteria, this appears to be a case for reverting the
static LSM patch.
Jan, I remember you posting this last year and IIRC, there were really
only coding style issues to be addressed. There were some review queries
and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers --
certainly not now that security architecture and security model objections
are out of bounds.
So, I would suggest reposting the code for upstream inclusion, which
would be better at least in terms of upstream maintenance, as your code
will be visible in the tree.
- James
--
James Morris
<jmorris@namei.org>
-
