Date: Sun, 19 Aug 2001 23:33:56 -0400 From: "Ken Cross" <kcross@ntown.com> To: "Robert Watson" <rwatson@freebsd.org>, <freebsd-security@freebsd.org> Subject: Re: DENY ACL's Message-ID: <01ee01c12928$f11fd370$0200a8c0@kjc2.com> References: <Pine.NEB.3.96L.1010819203225.34466D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the feedback. In NT (or Win2K), ACL's actually apply to *everything*, not just files, but the evaluation is the same regardless. Each Access Control Entry (ACE) in the ACL consists of: * Type (Allow or Deny) * Security ID (SID, basically an elaborate uid or gid) * Access mask -- bit mask of what access is being requested The access check is straightforward: 1. If a Deny ACE exists for the requesting user (i.e., the user's SID or any of his groups' SID's match), access is denied. 2. If an Allow ACE exists for the requesting user, access is allowed. 3. Otherwise, by default, access is denied. Since the users we're working with are in the Windows environment, they'll expect similar behavior. My initial thoughts were just to add step 1. above and then fall through to the existing checks. Heck, if somebody goes to the trouble of setting a Deny ACE, we really need to make sure that user/group gets denied. Step 2. could be the existing ACL tests. I think Step 3. could be accomplished by setting the "standard" mode bits to 000. That way, they'd only get access if an ACE allowed it. All access is via Samba, though, so there could be some goofy things done there. But behavior should be consistent, so I'd rather see it in the filesystem/kernel. Good idea about checking in on the Posix.1e mailing list -- I'll do that. (What's the URL?) Ken ----- Original Message ----- From: "Robert Watson" <rwatson@freebsd.org> To: "Ken Cross" <kcross@ntown.com> Cc: <freebsd-security@freebsd.org> Sent: Sunday, August 19, 2001 9:29 PM Subject: Re: DENY ACL's > > On Sun, 19 Aug 2001, Ken Cross wrote: > > > The current Posix.1e ACL implementation in -current works great as far > > as it goes. I'm sure this has been kicked around before (although I > > couldn't find anything in the archives), but it seems like adding "deny" > > ACL's would be a useful and fairly straightforward extension. > > > > For those not familiar with it, deny ACL's are ACL's that explicitly > > deny access, e.g., group Accountants are allowed access, but user George > > is denied access even though he is a member of Accountants. > > > > They are used extensively in the Windows NT/2K world and I need to > > support them on a BSD platform. The implementation is pretty > > straightforward -- always check deny ACL's first and then access ACL's. > > They'd just be a new acl_type_t value (ACL_TYPE_DENY?). > > > > I'd be happy to help with the implementation (especially since I'll be > > doing it regardless). Any interest or things I should know about? > > There are some interesting questions about how you would combine the > POSIX.1e ACL evaluation with subtractive rights of the sort you're > talking > about. POSIX.1e does evaluation by a combination of first/best match. > It evaluates based on a "first match" of the general class of rights, and > then "best match" within that class. Here's the current algorithm based > on what's defined in POSIX.1e: > > Select a "matching" class using the following: > > (1) if effective uid == the file owner, then the file owner permissions > are used > > (2) if the effective uid == one of the additional users, then the > additional user permissions in question are used > > (3) "best match" from effective gid and additional groups using the base > group permissions and additional groups. "best" in this case is defined > as the first gid match that grants all the rights requested. I don't > believe that, in the event there are multiple matches, there is a defined > ordering for the match, but in the FreeBSD implementation, it matches the > effective uid before additional groups. > > (4) other > > So, if you want "subtractive rights" that mix with positive rights, we'll > actually need to fundamentally modify how the algorithm executes. Right > now, it is possible to express some sorts of "negative" rights by taking > advantage of knowledge of the fixed matching components of the algorith; > the "best" matching in the group section does foil some useful attempts. > > You might want to bring this up on the POSIX.1e mailing list, btw, and see > what thoughts the developers of other platforms have on the topic, or > whether this has been approached on other POSIX.1e-esque platforms. I'm > glad that the existing ACL implementation is coming in useful for you. > > 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?01ee01c12928$f11fd370$0200a8c0>