Re: Making forward progress

jmjonesat_private

On Mon, 6 Aug 2001, Crispin Cowan wrote:

> Stephen Smalley wrote:
> 
> > On Mon, 6 Aug 2001 jmjonesat_private wrote:
> >
> > > 1) the more patches/work that get done within the "restrictive_only"
> > > model, the more work have to do here to convert from "restrictive_only" to
> > > authoritative.
> >
> > Moving DAC to a module is not the same thing as authoritative hooks. I think
> > that Crispin sent a note to Ted asking about moving DAC to a module, not
> > about authoritative hooks vs. restrictive hooks.
> 
> Stephen is correct:  the question put to Ted is about moving the DAC logic.
> The authoritative/restrictive quesion is one we should likely decide
> internally.
> 
> Also, keep in mind that I put that question to Ted Friday afternoon, and it is
> only Monday morning.  It's a bit early to declare Ted AWOL :-)
> 
> 
> > With regard to authoritative hooks, it isn't really true that there is any
> > conflict between the ongoing work and what is needed for authoritative
> > hooks.  In fact, moving the existing hook calls after the DAC logic (which I
> > did for permission in my recent patch and I have just done for setattr,
> > ptrace, setnice, setpgid, and setscheduler) makes it easier to convert to
> > authoritative hooks. The other tasks I suggested in my original message in
> > this thread don't really help with regard to authoritative hooks, but they
> > don't make it any harder to change to them, and they certainly improve the
> > overall quality of LSM.
> 
> I also agree with Stephen's assement here:  I don't see a desparate need
> to resolve the restrictive/authoritative issue immediately.  In fact, I
> think there is much to be said for moving cautiously:  It is likely much
> easier to go restrictive->authoritative than it is to go
> authoritative->restrictive (obvious reasons IMHO, details if someone
> wants 'em).  So if we are to make the jump, we had best be certain that
> we want to. 
>

Very reasonable.  Although I can not envision a means of moving in-kernel
checks OUT without pre-requiring authoritative hooks.

I suggest this:

1) make hooks authoritative,

2) DON'T buy-in the DAC-OUT yet, but keep an open mind,

3) CREATE, approve, review, whatever, a stackable module that enforces
   hooks as restrictive_only, to address the obvious need.  It's really
   not even minimally difficult.

If the difference is not too great, as you say, then go to
authoritative... that will address my module's needs as well as every 
other module's need as has been posted here.

As far as the question: if Linus/Ted responds with "yes, pulling DAC out
might be entertainable and, actually, might be useful for reasons X, Y,
and Z...." where do restrictive_only hooks leave us now?

> Crispin
> 
> --
> Crispin Cowan, Ph.D.
> Chief Scientist, WireX Communications, Inc. http://wirex.com
> Security Hardened Linux Distribution:       http://immunix.org
> Available for purchase: http://wirex.com/Products/Immunix/purchase.html
> 
> 

J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module