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.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
