Re: Authoritative hooks updated to 2.4.13

From: Jesse Pollard (pollardat_private)
Date: Tue Oct 30 2001 - 05:43:43 PST

  • Next message: Stephen Smalley: "Re: Authoritative hooks updated to 2.4.13"

    Crispin Cowan <crispinat_private>:
    > 
    > Casey Schaufler wrote:
    > 
    > >Stephen Smalley wrote:
    > >
    > >>we need
    > >>a real security module that is open source that demonstrates the need for
    > >>these additional changes.  I don't think that the kernel developers will
    > >>be swayed by hand waving about unreleased or closed source security
    > >>modules.
    > >>
    > >Posix ACLs. If I bring you Posix ACLs on a silver platter will
    > >you give me authoritative hooks? Yes or no?
    > >
    > That strikes me as a problematic example, because it will end up either 
    > having dependencies on some particular file system that supports 
    > extended attributes, or being basically useless without the extended 
    > attributes.
    > 
    > Casey: how do you propose to deal with the extended attributes problem?
    > 
    > Rest of the list: do folks think that either a FS-specific module or a 
    > neutered :-) module would be a convincing argument?
    
    Actually, both.
    
    An inherent filesystem support (xfs or e2fs/e3fs, or both) has the advantage
    of guaranteeing synchronization between inode and ACL with the minimum of
    additional overhead.
    
    A separate implementation should be available for those file systems that
    don't support extended attributes. These filesystems will incur the added
    penalty of having a daemon provide search/retrieval/update functions for
    the ACL entries.
    
    The advantage of the separate implementation is more in testing; and
    having the support available.
    
    The filesystem supported extended attributes will provide some limits on
    what can be implemented. XFS could provide the most complete and flexible
    implementation since it keeps the attributes in a more amorphous format,
    usable for POSIX ACLs, but also for other items too (file migration data,
    system/user acls separately, ...) where ext2/3 are already aimed at POSIX
    ACLs and the storage format variation is much more limited.
    
    Both are desirable if only POSIX ACL support is to be provided. This would
    cover what I expect to be  about 90% (my assumption) of the systems in the
    field.
    
    -------------------------------------------------------------------------
    Jesse I Pollard, II
    Email: pollardat_private
    
    Any opinions expressed are solely my own.
    
    _______________________________________________
    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 : Tue Oct 30 2001 - 05:45:35 PST