Re: [RFC] protect against denial-of-service on a 4.0 mount

From: Chuck Lever <chuck.lever@oracle.com>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [RFC] protect against denial-of-service on a 4.0 mount
Date: Wed, 23 May 2018 09:05:40 -0700	[thread overview]
Message-ID: <08BCD5D3-AB29-49BE-BA5F-FE0DE6FBC515@oracle.com> (raw)
In-Reply-To: <CAN-5tyEW=O20F3Ag7WKi8Uk21-Z-+g2QWO-93zsukAN8K4ErRw@mail.gmail.com>

Hey Olga-

> On May 23, 2018, at 8:27 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
>=20
> On Tue, May 22, 2018 at 6:36 PM, Chuck Lever <chuck.lever@oracle.com> =
wrote:
>>=20
>> The question of whether the provided callback address is
>> valid is a different matter. "Is this user-provided
>> address one of my local interfaces or _ANY?" and then
>> either warn or fail the mount if not.
>=20
> clientaddr is advertised to the users for the callback information and
> yet the code uses it to construct the client id string.

To be clear, the only way the server knows about callback
information is because nfs4_proc_setclientid constructs a
cb_client4 argument to SETCLIENTID. The server treats
client ID strings as opaque blobs, used only for comparison
with other client ID strings. It does not matter that the
non-uniform client ID string we construct happens to have
random bogus crap in it, just as long as it is different
random bogus crap as any other client. ;-)

What matters is what goes in cb_client4.

> It should
> either not do so and acquire the IP information independently from
> what was supplied

The normal situation is that "clientaddr=3D" is not specified
by the administrator. Rather it is constructed by mount.nfs
and passed into the kernel with the other mount options.

(At least in the past) the kernel could not determine the
callback information by itself, which is why we have
clientaddr=3D in the first place.

I'm not sure from your original post why the admin was
supplying clientaddr=3D . I got the impression that it was
malicious, but maybe I am mistaken? Was there some problem
with the clientaddr=3D being supplied by mount.nfs ?

> or I think there should be a check on the user
> supplied input.

It's rare that an administrator would need to explicitly add
clientaddr=3D on the command line. But some input validation
is reasonable in the case where an admin (and not mount.nfs)
has specified this address.

> Would you support a patch that does the check and then (I'm making a
> choice here) fails the mount if the check fails.

I would need to know specifically what you have in mind for
"the check".

--
Chuck Lever