[OpenAFS-devel] security implications of letting non-system:administrator lock volumes?

Marcus Watts mdw@umich.edu
Fri, 06 Apr 2007 21:59:48 -0400


Adam Megacz <megacz@cs.berkeley.edu> writes:
> To: openafs-devel@openafs.org
> From: Adam Megacz <megacz@cs.berkeley.edu>
> Subject: [OpenAFS-devel] security implications of letting non-system:administrator lock volumes?
> Date: Fri, 06 Apr 2007 18:29:56 -0700
> 
> 
> I've been tinkering with changing fileserver/volserver to let any user
> with "a" rights on the root of a RW volume perform a "vos release" on
> that volume.
> 
> I quickly discovered, however, that this requires locking the volume,
> which is currently a system:administrators-only thing.
> 
> Could a user cause harm outside a volume by maliciously
> locking/unlocking it?  In particular, I'm wondering about the user
> causing corruption to other volumes on the same partition by forcibly
> unlocking a volume while something was being done with it.  Or perhaps
> crashing volserver/fileserver by corrupting his/her own volume.
> 
>   - a

I don't think you can crash anything with locking volumes alone.
The most you can likely do is confuse random cache managers.
On the other hand, the right to do "vos release" is pretty
much exactly the same thing as the right to do
a "vos restore" (to the fileserver), so anybody who can do these
can certainly corrupt that particular volume.  I don't think that
volserver/fileserver have any explicit paths here that would
enable corruption in one volume to affect any others, but on the
other hand, I don't think any of this code is necessarily particularly
ruggidized against that kind of monkeying around, you probably
don't want to expose this interface to malicious users.

Instead of modifying the fileserver/volserver to do this, I'd
instead recommend setting up some sort of intermediate server
that can do a volume release on behalf of authorized persons.
The intermediate server can do much more interesting validation
on operations you might want performed, and can run in a trusted
environment without exposing the underlying interfaces to persons
who should not have that access.  The classic tool to do this
is "adm".  Many sites have more modern tools to do this; one
possibility is the perl5 AFS module.  At umich.edu we have some
stuff that's based on an rx capable server that can do basic
authorization checks before invoking a perl script which
can do whatever is necessary.  One of the scripts we run with
this is capable of doing volume releases, on one particular
small set of volumes, by one very small group of users.
The perl script here doesn't even use the perl5 AFS module,
it just calls "vos release" with appropriate (ie, not the user's)
credentials, after validating the input and mapping it into the
appropriate set of volumes.

					-Marcus Watts