Re: Authoritative hooks updated to 2.4.13

From: Casey Schaufler (caseyat_private)
Date: Tue Oct 30 2001 - 09:50:57 PST

  • Next message: Greg KH: "Re: removal of the version field from struct security_operations"

    Stephen Smalley wrote:
    
    > SGI may be able to provide a POSIX ACLs security module that
    > doesn't depend on a kernel patch.  But I don't know what Casey had in mind
    > - I suspect that they do currently depend on the extended attributes patch
    > or on XFS.
    
    My issue is weather to hold it up for LSM. At this point, it
    looks most like the ACL work is going to have to go in without
    LSM, since LSM can't support it. That means special purpose ACL
    code. I can get the ACL work to use LSM if LSM can provide what
    ACLs need. I cannot prevent the ACL work from going in as an
    arguement against LSM, nor would I be particularly inclined to.
    
    ACLs will require a kernel patch with the current LSM. In particular,
    the mode bit checks must be circumvented (replaced) where an ACL
    is present. This is required by the semantics. No, you can't do it
    any other way, that's the way it's specified, and our five
    years experiance with the Irix implementation verify it. If the
    hook were authoritative, ACLs could use LSM for that part. With
    restrictive hooks the code must be patched.
    
    So, the point is that ACLs are an example of work being done
    today for which the current LSM fails to meet the stated
    purpose, requiring policy specific patches even with LSM.
    
    -- 
    
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 888.220.0607
    
    _______________________________________________
    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 - 09:54:37 PST