[OpenAFS] Ideas for finer grain set acl controls

[Michael Meffie]

Hello,

Andrew, Tom, and I would like to discuss and solicit feedback on
some ideas we have been considering to strengthen OpenAFS access
controls, especially for sites which provide AFS service over the
public internet.


Background
----------

Currently sites may give users administrative rights on certain
directories, such as home directories and shared project directories.
Users should not, but can, give overly permissive ACLs to those
directories. For example, a user could give write and even admin
permissions to the groups system:anyuser and system:authuser.

This can which can lead to problematic situations, especially for
directories that can be served over http. As it stands today, AFS
administrators can use the audit log to detect and correct ACLs
which are overly permissive, but this is an after the fact check.

For example, consider the case where users are given home volumes
and have the ability to control the ACLs in the directories of their
home volumes. A user with 'a' (admin) rights could do,

   cd /afs/example.com/user
   fs setacl john system:anyuser rlidwk

A nefarious party or program can now write inappropriate material to
/afs/example.com/user/john. If that if that directory is also made
available over a web server, then those files are hosted on the
organization's web site.

We would like to address the situation by providing a finer grain
control on the setting of ACLs, with the intent to prevent users
from intentionally or inadvertently violating their
organization's security policies.

An approach under consideration:

   * a per volume mechanism for finer grain restrictions on
     ACL changes for objects in the volume, which would use ACL
     restriction lists, stored as per-volume meta-data

   * use the per volume restrictions in addition to the current
     rights when a user is changing ACLs.

   * standardization of new rpcs to set and retrieve the per-
     volume meta-data (hopefully, just new tags for the
     tag-value rpc already being discussed on afs3-std)

   * new volume dump tags for any new per-volume-data

   * new utilities for auditing pre-existing volumes


Example
-------

For purpose of discussion, the following type of usage is
envisioned. The hypothetical commands and options are for
illustration only.

First, a site administrator, presumably a member of the
systems:administrators group, would use a new command to setup the
ACL policies for the target volume.  Let us say we want to have
finer grain control to the setting of access rights to the vnodes
on the volume user.john. A contrived example,

   Permit the user john to "grant read access to user jane"
   on vnodes in the volume user.john

A hypothetical command could be something like,

   setpolicy
     -grant
     -user john
     -set-rights rl
     -for-user jane
     -in-volume user.john

In a second example, let us say we want to restict the user john
from giving way write access (also insert, delete, lock, and
admin) to vnodes in his volume user.john.  Perhaps such a policy
could be set by,

    setpolicy
      -grant
      -user john
      -set-rights rl
      -on-user system:anyuser
      -in-volume user.john

Or perhaps we would want to prevent all users from granting
anonymous write access,

    setpolicy
      -grant
      -user system:anyuser
      -set-rights rl
      -for-user system:anyuser
      -in-volume user.john

After issuing such a command, a regular user would be limited to
setting 'r' (read) and/or 'l' (list) to system:anyuser in any
directory within the user.john volume. A user trying to set any
other ACL would be denied by the fileserver,

   cd /afs/example.com/user
   fs setacl john system:anyuser w
   fs: You don't have the required access rights on john

   fs setacl john system:anyuser r
   (success)

Of course, the volume may have pre-existing directories which have
the overly permissive ACLs. A separate tool would be needed to
perform an audit of the directories.


Super-groups
------------

We need to take into consideration nested groups (aka
supergroups). For example, assume for some reason, the group
system:anyuser is a member of the group project:mayhem.  This
creates a complication in that a user could set the ACLs for
project:mayhem, and transitively effect members of system:anyuser.
Consider a volume called project.mayhem, which is mounted at as
/afs/example.com/project/mayhem.

    setpolicy
     -grant
     -user system:anyuser
     -set-rights rl
     -for-user system:anyuser
     -in-volume project.mayhem

    pts adduser example:staff project:mayhem
    pts adduser system:anyuser project:mayhem

Since the pts group system:anyuser now a member of the
project:mayhem group, then the setting of the ACLs for
project:mayhem would also need to be restricted,

    cd /afs/example.com/project
    fs setacl mayhem project:secret rlidwk
    fs: You don't have the required access rights on mayhem


Your thoughts and input would be appreciated.

Thank you,
Mike