From owner-freebsd-security Sun Aug 19 18:53:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7F23B37B409 for ; Sun, 19 Aug 2001 18:53:40 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7K1rbP35318; Sun, 19 Aug 2001 21:53:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 19 Aug 2001 21:53:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jonathan Slivko Cc: Ken Cross , freebsd-security@freebsd.org Subject: Re: DENY ACL's In-Reply-To: <200108192137.AA78709278@stmail.pace.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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