[AFS3-std] Re: Methods of Restricting AFS3 ACL rights

[Chaskiel Grundman]

What you seem to be describing here fits within what I think of as the 
plain meaning of "Mandatory Access Control" (that is, access control that 
cannot be overriden by users), yet you do not use the term. Is 
that because of the potential for confusion with labeled systems or 
something else?

The mechanisms described seem rather ad-hoc and possibly tailored to the 
requirements of a small number of sites. Other sites might have other 
requirements (i.e. labeling with BLP-like no read up/no write down or 
Bipa-like no read down/no write up; or IP address / encryption / security 
mechanism restrictions). If we're going to make some significant change to 
the access control model, is this the one we want to make? Note: this 
point isn't a real objection, but I'd like to try and stimulate some 
discussion

> The existing security model is known to be flawed.
The existing security model isn't all things to all people. Is UNIX also 
flawed because I can chmod 777 $HOME?

> How modification of policy data will be authorized in an environment
> using RBAC is not clear.
formal RBAC is not well suited to network protocols that are not session 
oriented. (how do you select a role?)

If you really just mean that you want to implement least privilege and not 
grant full priviliges to (some of) the sysadmins, then you use a privilege
delgation system, such as remctl, to do the policy checks.

In any case, I don't see how the volume acls described here are special. 
Dumping/restoring volumes or (in some cases) modifying pts groups would 
allow you to bypass these restrictions.