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

[Olga Kornievskaia <aglo@umich.edu>]

On Wed, May 23, 2018 at 12:05 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> Hey Olga-
>
>> On May 23, 2018, at 8:27 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
>>
>> On Tue, May 22, 2018 at 6:36 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> 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.
>>
>> 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=" 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= in the first place.
>
> I'm not sure from your original post why the admin was
> supplying clientaddr= . I got the impression that it was
> malicious, but maybe I am mistaken?

In practice it was a simple misconfiguration on the part of the admin
that input an incorrect address. Mistaken or malicious attempt will
greatly interfere with a legitimate user.

> Was there some problem
> with the clientaddr= being supplied by mount.nfs ?

The problem is that clientaddr is allowed to be specified by the user
and have no checks before being used as an input to the client id
content.

>> 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= on the command line.

I guess not rare enough as it came up as a customer case.

>  But some input validation
> is reasonable in the case where an admin (and not mount.nfs)
> has specified this address.

I believe so and that's what I'm trying to accomplish.

>> 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".

I will make another attempt at the check to include allowing for the
0.0.0.0 and whatever equivalent of it is in ipv6.