Re: MAC before DAC vs DAC before MAC

From: Casey Schaufler (caseyat_private)
Date: Sun Jul 29 2001 - 14:16:39 PDT

  • Next message: David Wagner: "Re: MAC before DAC vs DAC before MAC"

    David Wagner wrote:
    > 
    > Casey Schaufler  wrote:
    > >Assume a file with both a POSIX ACL and a MAC label.
    > >The MAC label is small enough to fit in a XFS inode,
    > >the ACL is not. The file hasn't been accessed in so
    > >long its not only not cached, it's been archived
    > >by the HMS. The inode remains on disk, but the extended
    > >information, in this case the ACL, is off line.
    > 
    > Am I confused?
    
    Yes.
    
    > Doesn't this example actually argue that in-kernel checks
    > ("DAC") should precede module-based checks ("MAC", if we must use that
    > terminology)?  The kernel's inode check (which uses the "DAC" mode bits
    > stored in the inode) will execute quickly, but the module's ACL check
    > will take a long time, so if we're really talking about optimizing any
    > way possible, then we want the kernel's check to come first.  Right?
    
    No. You are assuming a file system implementation
    (all file system types are different, and you can't 
    assume that just because ext2 works one particular
    way that other file systems do, too) which keeps
    the traditional attribute information in "fast"
    access and extended information in "slow" access.
    You are argueing that I ought to compromise my security
    policy (MAC before DAC) because a particular file
    system implementation was inadequatley designed
    (doesn't do security attributes beyond mode bits well)
    to handle the facility.
    
    
    > Anyway, we could probably discuss at length about whether the right fix
    > for this type of example is a modification of the caching strategy,
    > a tweak to the security architecture, or education of customers and
    > management of their expectations.  Nevertheless, the most compelling
    > point for me is that this scenario is an event that I believe we can
    > expect to be rare.
    
    I weep. These cases are not rare, no matter how much
    I want them to be.
    
    > If we're going to allow performance arguments based on rare cases to
    > have such a large say in the architecture debate, what prevents some
    > other module writer from coming up with an argument that in-kernel checks
    > should come first because he has some scenario where the module ("MAC")
    > takes forever but the kernel ("DAC") is fast?
    
    I suggest that these performance arguements be abandoned
    completely. We provided these arguements because someone
    was saying there were no such cases, and claiming that
    they won because of it. Well, that's not right. 
    
    > For the record, I'm not convinced that SubDomain's application would
    > justify a sweeping change to the architecture, either, as SubDomain's
    > use of the current ordering might be viewed by some as a special case of
    > 'audit'.  From this point of view, you might be able to make a case that
    > there is no strong argument either way.
    
    I agree that performance is not a convincing arguement.
    I agree that SubDomain is a viable and potentially important
    architecture, as are MAC and Audit.
    
    -- 
    
    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 : Sun Jul 29 2001 - 14:18:34 PDT