[OpenAFS-devel] Authorization Checks for VL and VOL RPC interfaces

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig08DBF2EE652DFB0F8963AF31
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

AFS was designed and implemented without any requirement of
authentication let alone authorization checks for volume metadata
access with the exception being those that require "SuperUser" status.

It is also worth pointing out that the statistics gathering interfaces
are completely wide open.  The PR_ListEntry provides anonymous access as
well.  This e-mail will focus on the VL and VOL services.

For the VLService the SuperUser restricted RPCs are:

  CreateEntry[N]
  ReplaceEntry[N]
  UpdateEntry
  UpdateEntryByName
  DeleteEntry
  ChangeAddr
  GetNewVolumeId
  SetLock
  ReleaseLock
  RegisterAddrs

and the open RPCs are:

  GetAddrs[U]
  GetEntryByID[N,U]
  GetEntryByName[N,O,U]
  GetStats
  LinkedList[N]
  ListAttributes[N,N2]
  ProbeServer

For the VolService the SuperUser restricted RPCs are:
  CreateVolume
  NukeVolume
  DeleteVolume
  Clone
  ReClone
  TransCreate
  SetFlags
  Forward
  ForwardMultiple
  Dump[V2]
  Restore
  EndTrans
  SetForwarding
  SetInfo
  SetIdsTypes
  SetDate
  ConvertROtoRWVolume
  GetSize   (get size of a volume dump)
  SplitVolume

The open implemented RPCs are:
  GetFlags
  GetName
  GetStatus
  ListPartitions
  ListVolumes
  Monitor
  PartitionInfo[64]
  ListOneVolume
  XListVolumes
  XListOneVolume
  XListPartitions

All of these restricted operations permit changing the contents of the
VLDB or of the volumes themselves.  The unrestricted operations permit
querying the metadata.

The fact is that AFS was not designed to hide volume and partition
metadata from clients.  There are no access control lists on volumes and
partitions and neither the VL nor the VOL services have a dependency on
the PR(otection) service.

It should also be noted that as of the current releases the UNIX cache
managers always issue VL RPCs over unauthenticated connections.
Therefore, any restrictions on reading the contents of the VLDB would
prevent access from existing clients.  That implies that any future
distribution of an OpenAFS release that includes authorization checks
would need to default to system:anyuser.

The VOL service is not directly accessed by cache managers.  Permission
restrictions would not have an impact on them.

The VL and VOS services are both accessed by anonymous "vos" commands.
However, the "vos" commands default to authenticated connections.  As a
result it should be possible to add authorization checks on RPCs that
are not used by cache managers.

For the VL service those RPCs would be:
  GetStats
  LinkedList[N]
  ListAttributes[N,N2]

For the VOL service those RPCs would be all of the currently open RPCs.

I believe that it would be desirable to apply the existing AFSIDs and
access control list permissions (rlkidwa) augmented by "(m)ove,
r(e)lease, and (b)ackup" permissions.  Thereby permitting the assignment
of fine grained access controls that would allow further delegation of
volume management to trusted end users.

They could be applied as follows:

 * the VLDB as a whole

   (l) permits listing the database
   (r) permits reading entry information if entry specific
       permission permits
   (k) permits locks to be set on the database and on an
       individual entry if the user is permitted
   (i) permits creation of new entries
   (d) permits deletion of entries if the user has delete
       permission on the entry
   (w) permits updates if the user has write permission on
       the entry
   (a) equivalent to being a SuperUser

 * each VLDB volume group
   (l) permits reading the volume location information
   (r) permits reading other volume specific info
   (k) permits locking the entry
   (i) permits adding and removing replica sites
   (d) permits deleting the entry
   (w) permits updating the entry
   (a) not used
   (m) permits moving the volume -- implies (k)
   (e) permits releasing the volume -- implies (k)
   (b) permits backing up the volume -- implies (k)

 * each partition object
   (l) permits listing the volumes in a partition
   (r) permits reading the partition metadata
   (k) permits locking partitions
   (i) permits adding new volumes
   (d) permits removing volumes
   (w) permits adjusting volume quotas if the
       volume permissions permit
   (a) equivalent to SuperUser

 * each volume object.  VLDB volume group permissions are used.
   (l) not used
   (r) permits reading volume specific info
   (k) permits locking the volume
   (i) not used
   (d) not used
   (w) permits updating the volume status and motd
   (a) not used

To manage the new permissions will require a new set of RPCs that would
need to be standardized.  Any cell that applies these new permissions
would need to use a new "vos" command to manage the cell that is
permission aware.  A cell would need to block the use of existing tools
that are unaware of volume group permissions to ensure that they are set
appropriately when creating and moving volume instances.

Given the amount of work that will be involved in fully specifying,
standardizing, implementing and testing such a new feature, I am going
to stop here awaiting support from the community before taking
additional steps.

Jeffrey Altman



--------------enig08DBF2EE652DFB0F8963AF31
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQAyzHAAoJENxm1CNJffh4nqMH/iMIrU7qnOWa+pdxSJkBoVqe
qD9BYUBl2z0NidwisnEU5OCITMh73z4jlDLJ5k0oPLQHyrUEoKsudBhLRKrjra5u
10WR4nCweM6jITQpcOOskCie7YKmqzIX8NNDfou655H3O6h0DLe4Ep9NG1DC+pEw
vsiJpl14RbWbMmc2epA1eqB+CAZd9eVImLlAe2LopD6Fclzl5geqflUwF3D+MXYw
0Uc+I/QTC++EJhMtywhbQQqotLyK98JY4Ovi2Z1HJ8WcfswXN4seTsY2JUzD4RGw
N01TyCH0fxdPH+5+MGgNeEnCu3ispWOdBeP2+W950AuyAQwovx9SyQmFuYlqN2o=
=d8lT
-----END PGP SIGNATURE-----

--------------enig08DBF2EE652DFB0F8963AF31--