What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

hchat_private

On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
> WRT "taking away LSM patches": HCH wants to remove hooks that "no one 
> uses" and also complains about LSM being a big ugly undesigned hack 
> lacking abstraction.

> LSM does have an abstract design: it mediates 
> access to major internal kernel objects (processes, inodes, etc.) by 
> user-space processes, throwing access requests out to the LSM module.

We seem to use the term design differently.  And maybe my english
wording wasn't perfect (I'm no native speaker..).  My objection is that
LSM by itself does not enforce the tightest bit of security policy
design.  Your "design" is putting in hooks before object accesses
without making them tied to enforcing some security policy.

Now I hear people scream "but we want $BIGNUM totally different security
policies", but that;'s not what I want to take away.  Look at the Linux
VFS, it enforces quite a lot of stuff, and still we have tons of entirely
different filesystems.  Of course that could also have worked by putting
a function vector directly below the syscall level, similar to say the SVR3
filesystem switch.  But that means a) we duplicate tons of code because
filesystems are filesystem and there's stuff they will have to duplicate
anyway.  and b) there's stuff we just can't handle that way properly.
(see the cross-directory rename issue still present in most non-linux
unices).

Now getting a LSM-replacement in place that is as well-designed,
feature-rich and still rather slick as the Linux VFS won't happen
over night.  But if you see how we got that code is that we had
example filesystems that showed would should go into common code.

That's one of the reason why I think merging LSM-like hooks without
examples (three or four general purpose policies best) doesn't make
much sense.  We need to see what we can abstract out and how.

And here we see _the_ problem with the LSM process.  LSM wasn't
developed as part of the broad kernel community (lkml) but on
a rather small, almost private list.  People added hooks not because
they generally make sense but because their module needed it.
When reading this thread some people (e.g. David [*]) still seem that
changes should be done for LSM's sake - but that's entirely wrong.
The point of getting LSM or something similar in is for the sake
of the _linux_ _kernel_ getting usefull features, not for enabling
some small community writing out of tree modules.

> If 
> you remove some of these hooks because they don't have a *present* 
> module using them, then you break the abstraction.

An abstraction that isn't used is worthless.

	Christoph

[*] and btw, question in mails sent to a list I'm not subscribed to in
    reply to mails from me won't get answered, sorry.
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module