Re: Making forward progress

From: jmjonesat_private
Date: Mon Aug 06 2001 - 11:07:49 PDT

  • Next message: Stephen Smalley: "Re: Making forward progress"

    On Mon, 6 Aug 2001, Crispin Cowan wrote:
    
    > jmjonesat_private wrote:
    > 
    > > Very reasonable.  Although I can not envision a means of moving in-kernel
    > > checks OUT without pre-requiring authoritative hooks.
    > 
    > Neither can I, but since DAC-out is not likely to happen, I don't care very much.
    > 
    > 
    > > I suggest this:
    > >
    > > 1) make hooks authoritative,
    > 
    > Not yet.  I'm still waiting to hear whether the promised advantages are
    > real or not.  In particular, I want to know whether Smalley's style of
    > authoritative hooks (DAC-in, DAC-first, send DAC result to module as a
    > parameter, and let the module make the final decision) actually improves
    > SGI's situation.  Richard? 
    
    Riddle me this: how are they NOT real?  They allow me to build a module
    that does things differently than the 6 or 7 pre-existing security
    projects, but don't inhibit ANY of them from doing what they desire:
    proving that they can't grant permission when another model (even
    in-kernel) denies.
    
    As far as DAC-OUT, I'm still open minded, but, actually, like you... it's
    not something I can see as being useful... NOW.  My mind is still open,
    however.  There's NO way DAC-OUT can be implemented with restrictive_only,
    there IS a way with authoritative to guarentee restrictive_only (as it
    currently is) without much work...
    
    Why do you object?  This contradicts my opinion of you.
    
    
    > > 
    > > 2) DON'T buy-in the DAC-OUT yet, but keep an open mind,
    > 
    > Sorry, my mind is close on this issue :-)
    
    I'm very sorry to hear this.  I've always advocated you as having an open
    mind, and I don't think there's clear, irrefutable proof to the contrary,
    at this point.
    
    > 
    > 
    > > 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.
    > 
    > Sure, if #1 actually goes through.
    
    Good.  It's both possible and (easily) doable.  Ergo, we enable otherly
    functional solutions in the future with LSM without invalidating the
    assumptions of currently implemented solutions.
    
    > 
    > 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
    > 
    > 
    > 
    > 
    > _______________________________________________
    > linux-security-module mailing list
    > linux-security-moduleat_private
    > http://mail.wirex.com/mailman/listinfo/linux-security-module
    > 
    
    |>------------------------------------------------------
    ||  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
    



    This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 11:09:38 PDT