Date: Sun, 19 Aug 2001 21:53:37 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Jonathan Slivko <js43064n@pace.edu> Cc: Ken Cross <kcross@ntown.com>, freebsd-security@freebsd.org Subject: Re: DENY ACL's Message-ID: <Pine.NEB.3.96L.1010819214320.34466F-100000@fledge.watson.org> In-Reply-To: <200108192137.AA78709278@stmail.pace.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2001, Jonathan Slivko wrote: > But there is 1 thing that both of you forgot to account for, how much > load it would take in order for the deny ACL's to be loaded and to be > read, several times over in a given hour. Any comments on that front? -- > Jonathan I'm not sure I quite understand the question, but I can speak to the current performance of ACLs in 5.0-CURRENT. Right now, the actual cost of evaluating the ACL is almost negligible. The cost is incurred in the association of the ACL with a file or directory, in particular, due to the current implementation of extended attributes. For details on this, please see my BSDCon and FREENIX papers. The end result is that for un-cached ACLs, you pay a one-seek hit file access control operations (after that, the ACL typically remains in the cache, and you benefit from temporal locality a great deal). For complex operations on un-cached ACLs, you can pay a higher cost, such as for a multi-directory rename operation. As part of our recent DARPA CHATS grant, we have funding to reimplement the EA support in UFS at the FFS layer, with tight soft updates integration. We're still working with SPAWAR to finish our sub-contracting agreements so that our sub-contractors can start work on this. The suggested strategy of introducing an additional ACL type would require an additional EA read for access control decisions. Chances are, for a cached ACL, the cost of this would be unnoticeable. However, for an un-cached evaluation, the cost of access (especially sequential synchronous read operations) is non-trivial. Given that many consumers of ACLs don't use the full available 32 slots of struct acl, I would generally think that a more cost-effective approach would be to integrate the negative ACL entries into the base access and default ACLs. However, that then bumps into the issue I discussed in my previous e-mail, relating to the ACL evaluation algorithm. I'd be interested in learning more about the NT approach to negative ACLs: I know that AFS and Coda support this, but they use a fairly different evaluation scheme for ACLs, which lends itself to this negative notion of ACLs better. They inspect each ACL entry that is relevant, and union the set of positive rights, then subtract the union of the negative rights, without (as I understand it) the "best-match". I also dislike best-match because, when mised with a more fine-grained privilege model, it makes it very difficult to audit exactly what set of privileges authorized an action (as it leaves it ambiguous). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010819214320.34466F-100000>