Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig <hch@infradead.org>]

On Mon, Feb 10, 2003 at 11:55:41AM -0500, Stephen D. Smalley wrote:
> 
> Christoph Hellwig wrote:
> > Well, selinux is still far from a mergeable shape and even needed additional
> > patches to the LSM tree last time I checked.  This think of submitting hooks
> > for code that obviously isn't even intende to be merged in mainline is what
> > I really dislike, and it's the root for many problems with LSM.
> 
> back changes.  At present, the only significant change in the
> additional patch has to do with early initialization of SELinux so that
> we can properly set up the security state of kernel objects when they
> are created rather than needing to retroactively set up the state of
> objects created before module initialization.

And that for examples is a very important and needed change.  Security
modules as loadable modules are a bad idea as you don't have a consistand
labelling state - just look at the older selinux versions with all the
precondition mess.  But it should be generalized to a new initcall level
instead of the current explicit call to the selinux routine..

> > There has been a history in Linux to only implement what actually needed
> > now instead of "clever" overdesigns that intend to look into the future,
> > LSM is a gross voilation of that principle.  Just look at the modules in
> > the LSM source tree:  the only full featured security policy in addition
> > to the traditional Linux model is LSM, all the other stuff is just some
> > additionl checks here and there.
> 
> I assume that you mean "SELinux" above.

Yes, sorry.

> It is true that SELinux is the
> dominant user of the LSM hooks at present.  We would have been happy to
> submit SELinux as a direct kernel patch rather than adding a further
> level of indirection via LSM, but that wasn't the guidance we were
> given.

The problem is not really the indirection but the submission of the
indirection without it's users.

> > I'm very serious about submitting a patch to Linus to remove all hooks not
> > used by any intree module once 2.6.0-test.
> 
> Any idea on how much time that gives us (to rework SELinux and submit
> it)?

Unfortunately I don't decide about the linux 2.6 freeze - ask Linus.

> Some of the necessary changes are simply engineering issues, but
> others require further dialogue, e.g. getting the API into an
> acceptable form, revisiting the approaches used to label and control
> access to pseudo filesystems.

+ moving to extended attributes instead of magic files for storing the
  labels on filesystems
+ getting the patent issue sorted out

> Leaving 2.6 with no infrastructure for access control extensions at all?
> Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
> to a more directly integrated architecture in 2.7?

Personally I prefer to not have infrastructure in over having broken
infrastructure.  Looks at what the devfs mess caused in 2.4 and how much
was removed or is beeing removed/rewritten again in 2.5.  Life would have
been a lot simpler if it never got in during 2.4.  Similarly I don't see the
problem why the current lsm users can't keep using patches during 2.6.