[OpenAFS] Re: fs setacl and permissions

[Bob Cook]

>On Wed, 24 Jan 2007, Frederic Gilbert wrote:
>
>> Derrick J Brashear wrote:
>>>> On the other hand, we found out that one can apply "fs sa" on a
>>>> directory, even if he is not in the ACL table, and even if he is not the
>>>> directory's owner, but if he is the owner of the mounting point of the
>>>> volume where the directory resides.
>>>
>>> The latter behavior was always true. the change to the former is new in
>>> 1.4, i don't remember the rationale but it was discussed on the list.
>>
>> Thank you for your answer.
>> I tried to look for the discussion on -info and -devel with some obvious
>> keywords, but did not found it (I will try my luck again later).
>> However, unless I missed something again, the files documenting "fs setacl"
>> in openafs-1.4.{1,2}-doc.tar.gz always speak only about directory's owner
>> (the three lines in my original post), which is confusing.
>>
>
>I'm not arguing your point. We should fix one or the other, though, I'm
>not sure which. I will try to find the discussion.

This topic was discussed at the first OpenAFS user meeting ("user meeting"
isn't the right name, but I can't remember the official name) held at SLAC
mumble years ago, organized by Alf Wachsmann.  That may be what you're
remembering.  SLAC and some other installations supported the position of
wanting to prohibit conferring "a" privs automatically on the owner of a
directory.  Evidently we convinced Derrick because he agreed to fix it.
And evidently, he has recently done so.

So, why did we (at least SLAC, where I used to work before retiring) consider
it a security problem?

The "a" privilege is AFS's mechanism for (1) controlling access to space; and
(2) allowing that control to be delegated to others without requiring special
privileges.  Let me accompany such general remarks with a specific example.
Suppose you have been allocated some disk space, e.g. for your home
directory, or for a project you are heading up.  You start out with a
top-level directory whose ACL specifies that you (via your userid or an AFS
group to which you belong) have "a" privileges (and probably the other six
too).  At some point you may very well wish to subdivide the space and
allocate some of it to a subproject or a colleague or a group of colleagues.
So you define a subdirectory and specify who controls it by assigning the
appropriate person/group the "a" privilege.  You probably also keep that
privilege for yourself in the new subdirectory so that you can monitor the
space, and so that you maintain control of it.

I claim that this is quite common behavior; AFS is well-suited for it.  In
fact, one nice AFS feature that helps is that any new directory inherits its
initial ACL from its parent directory.

Now what happens to this picture if the owner of a directory automatically
gets "a" privileges.  Well, the subdirectory you defined for your subproject
won't be affected, because you own it.  But (presumably) some of its
subdirectories, or subsubdirectories, will be created and thus owned by
others.  And even though you may have set up the initial ACL to allow only
certain people (and maybe just yourself!) to have "a" privileges, you have
probably restricted others to lesser privs.  However, anyone who has "i"
privs can create a subdirectory, and thus can not only add to or modify the
people you've given access, and what access they have, but any such owner can
in fact remove your privileges entirely from his subdirectory and all of its
descendants.  In other words, if that happens, you have completely lost the
ability to see how the space is being used, or by whom.  You can't even find
out how much space is being used.  You have lost control.

Picture a teacher who defines a "project" for each of her classes with such
a subdirectory.  She defines a subsubdirectory for each student and puts a
perfectly reasonable ACL like this in each one:

  system:administrators rlidwka
  <teacher> rlidwka
  <student> rlidwk
  <group of students> rl

Now any one of these students can define a subdirectory of his subdir and
remove the entry for <teacher> (and for system:administrators, though that
has less effect).  The teacher can see the directory she defined for that
student, but no lower.

In its simplest terms, the ability to create a directory has allowed someone
to completely subvert the control supposedly assured to the higher level
person.  Note, in fact, that even system:administrators can be subverted by
someone adding privileges or users to ACLs that system:administrators does
not want!

So what it really comes down to is this: I claim that, if someone who "owns"
a directory (i.e. has "explicit" a privs) defines a subdirectory and restricts
someone else to non-a privs there, it is really a security breach for that
someone else to be able to get "a" privs anywhere below it.  But that's
exactly what this "implicit a privs for a directory's owner" provides.