[OpenAFS-devel] Lockdown for VL and VOL RPC interfaces for non-authenticated user (was: Authorization Checks for VL and VOL RPC interfaces)

[Gergely Risko]

Hi,

Jeffrey compiled a good overview of open RPCs in VL and Vol in 2012
July, then proposed some authorization changes to make this compatible
with lockdown if an administrator desires.

Unfortunately nobody replied and the proposed changes are a bit heavy to
implement without any interest from the communities side. :(

I also found this issue today and this bothers me a bit, so I'd like to
ask if there are any arguments against doing something very simple right
now:

  - implement a new option for davolserver and vlserver:
    - default is that nothing is changed,

    - "sysadm only" means that only authenticated system administrators
      can issue the RPCs,

    - "anyuser" means that only authenticated users of the cell can
      issue the RPCs;

  - of course we wouldn't touch any RPCs that are needed for client
    operation.

If I volunteer to create the patchsets needed for this proposal, is
there willingness to review and merge them?

Also, are there any other RPCs in other services with significant
information leakage?  I played around with the PR ACLs, but PR_ListEntry
seems to be protected now (when using s---- fields), but is there
something maybe in fileserver?

I think this leak is significant to be bothering:
  - spammers can get valid email addresses,
  - spammers can confirm based on the stats the list of users that are
    actually active on a computer system,
  - from the vol stats people can monitor and figure out if someone is
    at the computer using AFS which can be part of a bigger social
    attack or harrasment scenarios.

So I'm happy to fix this if there is willingness to accept my help.

Thanks,
Gergely

On Sun, 15 Jul 2012 16:49:09 -0400, Jeffrey Altman <jaltman@your-file-system.com> writes:

> 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