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