Re: Kernel Security Extensions USENIX BOF Summary

From: Stephen Smalley (sdsat_private)
Date: Thu Jul 05 2001 - 11:09:30 PDT

  • Next message: Chris Wright: "Re: LSM Patch Additions for CAPP (C2) Audit Trails"

    On Tue, 3 Jul 2001, Crispin Cowan wrote:
    
    > I'd like to better understand this suggestion.  Various modules (DTE,
    > SubDomain) really do need the absolute path of the file being accessed.  If
    > there is not a hook that provides that information, then there needs to be a
    > way to reconstruct the info.  I'm assuming that "Doug's suggestion" is such a
    > means?
    
    You don't need the absolute pathname at the time of the lookup or
    file creation operation.  Suppose that you represent your pathname-based
    configuration as a tree.  When a file system is mounted, you can set
    a field in the security object of the root directory inode to point
    into your tree at the appropriate point for the absolute pathname
    of the mount point (easily accessible at that point).  [You need
    an equivalent to the old add_vfsmnt hook for this purpose or at
    least a post_mount hook.]  On subsequent lookups, you can set the field in
    the security objects for directories and files in that file system by
    starting from the location in the tree referenced by the parent directory
    inode's security object and looking up the component name in your tree.
    
    Doug suggested an inode-based approach like SELinux for assigning types
    to existing files, but noted that you could use this kind of approach
    (similar to the approach used by the NAI Labs' DTE prototype) to provide
    the ability to assign types to files that don't exist yet.  In that
    case, the tree would only contain leaf nodes for files that don't exist.
    But you could use the same approach for all files (as in the NAI Labs'
    DTE prototype).
    
    Keep in mind that at a high-level, SELinux uses pathnames as well.
    But these are mapped down to inodes during initialization, thereby
    avoiding the well-known problems with changes to the namespace and
    object aliasing.  Using inodes at runtime seems preferable to us -
    you want to protect data contained in an object, not a pathname.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    
    
    _______________________________________________
    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 : Thu Jul 05 2001 - 11:11:28 PDT