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

[Jesse Pollard <pollard@admin.navo.hpc.mil>]

On Wednesday 12 February 2003 05:05 pm, 'Christoph Hellwig' wrote:
> 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.

Actually - one of the requirements was to be able to REMOVE all hooks to
create a system with NO added overhead. The VFS does add overhead, but the 
flexibility dictated that it be accepted.

> 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.

That wasn't true either - as I recall, the group that started working on LSM
was strongly suggested to take it off the list until "show me the code" could
be done.

> > 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.

Ummmm. Not all of the SCSI options are used either. Does that make the SCSI 
layer worthless?

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.