On Thu, 14 Jan 2010 16:56:49 -0500 (EST) Chaskiel Grundman <[email protected]> wrote:
> 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? This is probably because the problem was originally described as "let me give people 'a' while still preventing them giving access to anonymous users" and has extended from there. I recognize that that could be considered MAC (a very specific case of it, but MAC nonetheless), but it seemed so specific in what it solved, that describing it as a MAC mechanism seemed to imply that it does more than it does (so, "confusion with labeled systems", yes). But yeah, if it would help to just use that term, it makes sense to me. > 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 Thank you for trying :) While I recognize that implementing something to reflect such confidentiality or integrity models like that is useful to some sites (I'm assuming governmental at least?), I _personally_ don't really have the background or interest to help design something like that. The other authors may have more to say... But I'm just trying to solve the problem at hand, and solving just the special case of restricting system:anyuser was deemed too narrow in scope (at least for OpenAFS). > 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. If you dump to a server that doesn't understand the new acls, sure. But we could prevent you from doing that, or have some toggle to allow/prevent it. I'm not sure I see how modifying pts groups still allows you to bypass it. Unless you just mean if a user can take themselves out of a group that is specified in the acl. If they can do that, well, they've taken away the one identifying feature that we know to restrict them by. We can't really fix that without some serious retooling (which is what I would guess is what you're getting at above?). -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
