[OpenAFS-devel] Re: safe dropboxing in an anonymous world

[Jeffrey Altman]

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

On 2/7/2011 3:09 PM, Steve Simmons wrote:
>=20
> On Feb 7, 2011, at 2:04 PM, Jeffrey Altman wrote:
>=20
>> If the Unix CM is reading beyond the end of file as part of preparing =
a
>> chunk to be written, that sounds like a bug to me.  The Windows CM nev=
er
>> reads data from the file server beyond the known EOF.  If the file is
>> new, the file length is 0 and the client prepares the page locally
>> without file server interaction.
>=20
> Agree, but . . . we really don't want to have functionality on the serv=
er that will allow malicious clients to read data they shouldn't be able =
to. We can say it's a client bug all we like, it's still the server handi=
ng out data it shouldn't._______________________________________________

The file server is working as it was designed.  If the owner of the
object matches the issuer of the request and the ACL says the requester
has 'i'nsert permission then the requester is permitted to read and
write.  There is no file descriptor between the client and the server
that the server can use to discriminate between a FetchData or StoreData
received from a client immediately after a file creation and one that is
received for some other reason.

This trade-off is relatively safe with authenticated users.  However,
when the dropbox is created for anonymous users it becomes troublesome.
What Derrick's proposed change (http://gerrit.openafs.org/#change,3901)
does is say that an anonymous client is not permitted to read from a
dropbox that is "system:anyuser li" under any circumstances.  If
directory owner wants system:anyuser to be able to read, she/he needs to
specify "lri" as the rights list.

My concern is that such a change is not good enough.  Most sysadmins are
not going to understand that a file owned by anonymous with a
"system:anyuser li" rights list gives any anonymous user the ability to
truncate or overwrite the contents of the file.

If the goal is to permit anonymous submission of homework for example,
this model is simply not safe under any circumstances.  That is why I
proposed a configuration option to disable the use of 'i'nsert with
anonymous.  Answering Andrew, Mike Meffie's change (gerrit/217) is
different.

The text that Steve is responding to is not claiming that a bug in the
client is permitting data to be read that the user does not have
permission to access.  The statement is that the client is reading more
data than it required in order to complete the operation of writing data
to a newly created file.  If the length of the file on the file server
is zero bytes, the client should not be trying to read a chunk from the
file server before it extends the length of the file locally.
Such a FetchData request from the client in conjunction with Derrick's
proposed change would result in an EACCES abort being sent to the client
in the case where an anonymous user is attempting to write to a file
with "li" rights.

The correct long term solution to fixing this is to change the protocol.
 The file server would respond to a successful CreateFile request with a
cookie that must be provided inconjunction with all future FetchData and
StoreData requests that are expected to succeed as a result of 'i'nsert
permission.  The problem with making such a change today is that it will
break environments in which sites are explicitly counting on the
existing behavior and it would prevent 'i'nsert from working with the
existing deployed client base.

I do not believe we are at a point where making such a change is
acceptable.  I think the best we can do in the short term is a
combination of:

 * Derrick's proposal (gerrit/3901)

 * Providing an option to disable 'i'nsert for anonymous client

 * Improving our documentation to make it clear that system:anyuser "li"
   and anonymous users are not a secure mix.

Jeffrey Altman








--------------enigBCF4F33326E7C7F27B6EE0DE
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)

iQEcBAEBAgAGBQJNUHJEAAoJENxm1CNJffh43IcIAIQwGAfTDeCZgi46BVYrYvNH
3OmK/FH7TLuaFIJoNtD+9CnTA6UFOQeUcT9n5sj83NB84+BhKzPBhUZlG/FmSLhq
exyVupPsk8+nZtRMuOFiPOGYikU2YHveAoZbEaSA2vI/OvRW+lZrfitIAV8oCPzT
rGFLb0nLqxN3sdZfUi0v9z4Z5tbTOVzI5wkwi5pYW34vlck+c1Zavc4AsRSRosJL
tnZ46CIrX8CDUyPZrnm18Tjk6RImOUiWMzsY5OqyLLelUwwmjP/Tgos08eMwXH4V
cSpfr+bDuWp2aN1XFvhzQOoi4Br7pIsn5NFCmes8u7bKn+qb4pL5TcqTRdFAAeM=
=0h70
-----END PGP SIGNATURE-----

--------------enigBCF4F33326E7C7F27B6EE0DE--