Restricting AFS ACLs

If you’ve ever administrated a sufficiently large and public AFS cell, you have probably at least once had a user assign rlidwka rights to system:anyuser on a directory. This can be a real security headache, particularly when web-accessible data is pulled directly from AFS. The only way currently to make sure that doesn’t happen is to revoke users’ admin rights, but then you lose the convenience and flexibility of users maintaining permissions themselves.
Arguably, this problem can be solved by user education and performing audits of ACL rights, but that isn’t always enough. Sometimes there are simply too many users, and/or the cost of them making a mistake with ACLs is just too high. Clearly, we need a way to specify an enforceable security policy, so too-permissive ACLs cannot ever be set.
To solve this, Mike Meffie, Tom Keiser, and I have been writing an Internet Draft that proposes three different ways to specify such security policies. It is currently available at http://bm1vsrv05.sinenomine.net/~adeason/draft-deason-afs3-acl-restricti....
Here is the Abstract:

The AFS-3 ACL ‘a’ bit gives users unfettered power to grant, or revoke, privileges, with no provision for enforcing site policy. This memo provides several alternative mechanisms for creating restrictions on what powers the ‘a’ bit denotes. Three alternative mechanisms for restricting the power of the ‘a’ bit are proposed: a method for overlaying the ACL with a site-controlled ACL; a method for masking the ACL with a site-controlled privilege mask; and a finely granular meta-acl mechanism for restricting to whom prvileges may be delegated, and which privileges may be given to different classes of principals. This memo will serve as a basis for the ACL restriction discussion with the AFS-3 protocol working group. The intended goal of this discussion is to reach consensus on standardization of one or more solutions, and then publish a BCP status memo.

If one of these methods in particular sounds best, or this just sounds useful to your or your organization in general, we encourage you to let us know. We welcome any feedback or discussion on the openafs-info mailing list.