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

[Andrew Deason]

On Thu, 14 Jan 2010 16:56:49 -0500 (EST)
Chaskiel Grundman <cg2v@andrew.cmu.edu> 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
adeason@sinenomine.net