Re: NFSv4

From: jmjonesat_private
Date: Sat Aug 04 2001 - 14:55:30 PDT

  • Next message: Jesse Pollard: "Re: NFSv4"

    On Sat, 4 Aug 2001, Crispin Cowan wrote:
    
    > jmjonesat_private wrote:
    > 
    > > Actually, it does seem to be a similar problem, at least to me (I'm 
    > > admittedly deep enough to get "the bends" here.)  Since you've moved
    > > this to a branch thread, I will pursue it briefly...
    > 
    > As a general practice, I try to re-label threads when branches appear. 
    > The "making progress thread" is ripe for that, as it addresses half a
    > dozen issues at once.  Re-labeling the brances makes it easier for
    > people to follow the issues they care about. 
    > 
    
    Smart policy.  Works well, and it's why I followed this here, since I
    don't see it as central to the previous thread.
    
    [...] 
    
    > I suspect the way it will play out is:
    > 
    >    * extended attribute file systems become more popular (NFSv4, EXT3, Reiser, etc.)
    >    * LSM wants to mediate the extended attributes
    >    * VFS gets enhanced to access extended attributes
    >    * LSM hooks get placed into the VFS extended attributes functions
    > 
    > > I'm not convinced that "special filesystems" are common enough to call 
    > > them the "general case."
    > 
    > Not yet, but they will be.  In the near term, the non-requirement for
    > extended attributes gives models like SELinux and SubDomain an advantage
    > over more classical security models like MLS, which require Security
    > Labels[tm] on files. 
    
    Likely true.  This leaves my only question about NSFv4, at this point,
    being:
    
    Can we make any small changes now that will facilitate this change in the
    future without imposing great cost now based on unknown factors?  I'd hope
    somebody will say "YES, just do this...", and demonstrate how it will ease
    the future. 
    
    Ergo, I'll watch NSFv4 and similar (fancy filesystems with extended
    attributes) issues with an eye toward LSM going awry, but without other
    info, I can't see it as a current issue until the VFS leads the way.
    
    HOWEVER, this doesn't critically impact the authoritative hook issue or
    the idea of moving DAC out, imho, (pro the first, undecided on the second,
    here) and I was trying to decide if it did.  I think extended
    attribute support will eventually NEED authoritative hooks to be fully 
    functional... allowing any assumptions made within the kernel to be
    exorcised.  Better now than later, imho, and I think there's ample
    justification just based on the current world, without having to guess at
    how NFSv4 will play out.  
    
    I'll take my thoughts on THAT debate (if and when I develop any new ones)
    back to the other thread...  :) 
    
    > 
    > 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.htm
    > 
    
    Sincerely,
    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
    



    This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 14:56:37 PDT