RE: lsm truly "generic" allowing complete choice? Clean? Simple? Idon't think so.

RE: lsm truly "generic" allowing complete choice? Clean? Simple? Idon't think so.

[LA Walsh]

> From: Russell Coker
> linux-kernel mailing list removed from the CC list (again), they've 
> probably heard too much of this discussion already.  
---
	It was isolation away from the mainline kernel list that allowed
the current patchwork design.  Attempts to clarify the LSM list charter
which ended up on lkml resulted in movements to silence those 
questioning the emperor's new clothes (or lack thereof).  LSM project
members want their changes in the kernel code *today*.  It is appropriate
to discuss design methodolgy on the kernel list since design
methodology discussion was forbidden on lkml as was any interaction 
with the linux community.  Quite frankly, the brown-nosing, back-slapping
politics really put a bitter taste on things that were naively believed
to be based more on technocracy than making people 'look good' and
commercial self-interest.

> If making the DAC code a module slows down non-LSM servers 
> and takes a lot of 
> programmer time to implement, is it a useful effort?
---

	It was already done -- the mainline kernel modules were done in
about 2 person-months of motivated programmer time.   There was no measured slowdown of non-LSM servers.  Changes done earlier by
the same project
lead of that project had all changes in the mainline kernel code compile
to nothing when compiled out.  Performance was a consideration in the
implementation.

-l

Re: lsm truly "generic" allowing complete choice? Clean? Simple? Idon't think so.

[Christoph Hellwig]

On Wed, Feb 12, 2003 at 01:58:53AM -0800, LA Walsh wrote:
> > From: Russell Coker
> > linux-kernel mailing list removed from the CC list (again), they've 
> > probably heard too much of this discussion already.  
> ---
> 	It was isolation away from the mainline kernel list that allowed
> the current patchwork design.  Attempts to clarify the LSM list charter
> which ended up on lkml resulted in movements to silence those 
> questioning the emperor's new clothes (or lack thereof).  LSM project
> members want their changes in the kernel code *today*.  It is appropriate
> to discuss design methodolgy on the kernel list since design
> methodology discussion was forbidden on lkml as was any interaction 
> with the linux community.  Quite frankly, the brown-nosing, back-slapping
> politics really put a bitter taste on things that were naively believed
> to be based more on technocracy than making people 'look good' and
> commercial self-interest.

Full agreement here.  If the LSM stuff actually was discussed on the
appropinquate list (lkml) we probably wouldn't have much of this mess.

> > If making the DAC code a module slows down non-LSM servers 
> > and takes a lot of 
> > programmer time to implement, is it a useful effort?

First making it a _module_ is silly.  In fact the idea of security
_modules_ is very bad - you need early initialization to have prope
labelling of all objects and subjects in the system.

Having DAC optional by itself sounds like a silly idea, but if it is
a fallout of a generic security model I don't see any reason why we
shouldn't allow it.