Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Chuck Lever <chuck.lever@oracle.com>]

On 5/25/25 9:47 PM, Rick Macklem wrote:
> On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
>>
>> On Mon, 26 May 2025, Chuck Lever wrote:
>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>> Hiya Rick -
>>>>
>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>
>>>>> Do you also have some configurable settings for if/how the DNS
>>>>> field in the client's X.509 cert is checked?
>>>>> The range is, imho:
>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>    the client's IP host address.
>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>
>>>> I've been told repeatedly that certificate verification must not depend
>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>> in the certificate's SAN.
>>>>
>>>> I recognize that tlshd will need to bend a little for clients that use
>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>> Perhaps client certificates do not need to contain their peer IP
>>>> address, but server certificates do, in order to enable mounting by IP
>>>> instead of by hostname.
>>>>
>>>>
>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>
>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>> rather than a particular implementation that might have historical
>>>> reasons to permit a lack of security.
>>>
>>> Let me follow up on this.
>>>
>>> We have an open issue against tlshd that has suggested that, rather
>>> than looking at DNS query results, the NFS server should authorize
>>> access by looking at the client certificate's CN. The server's
>>> administrator should be able to specify a list of one or more CN
>>> wildcards that can be used to authorize access, much in the same way
>>> that NFSD currently uses netgroups and hostnames per export.
>>>
>>> So, after validating the client's CA trust chain, an NFS server can
>>> match the client certificate's CN against its list of authorized CNs,
>>> and if the client's CN fails to match, fail the handshake (or whatever
>>> we need to do).
>>>
>>> I favor this approach over using DNS labels, which are often
>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>
>>> What do you think?
>>
>> I completely agree with this.  IP address and DNS identity of the client
>> is irrelevant when mTLS is used.  What matters is whether the client has
>> authority to act as one of the the names given when the filesystem was
>> exported (e.g. in /etc/exports).  His is exacly what you said.
> Well, what happens when someone naughty copies the cert. to a different
> system?

When that copy is discovered, the server can use a CRL to fence the use
of the copied certificate (and as Rik T. pointed out, NFSD does not yet
support that kind of mechanism).


> --> It is true that verification will show that the cert. is valid, but is it
>       valid for that client system?
>      (Not checking the reverse DNS name makes the check somewhat weaker,
>        imho. Now, is having the IP address in the cert. and checking
> that stronger.
>        Well, maybe. The hassle is that the certs. all have to be replaced when
>        some network type decides to reconfigure the LANs or move the system
>        onto a different subnet for some reason.)

None of that works for NFS clients whose name and address are
dynamically assigned.


> Another way a cert. can be protected from being moved to a different client
> by someone naughty is adding a passphrase to it (the -aes256 option on
> the openssl command line when creating the CSR). The hassle is that
> someone has to type the passphrase in when the system is started/rebooted.
> 
> There is no perfect solution (or security is not a binary value, if
> you prefer), so
> I chose to provide as many options as I could, so that sysadmins could choose
> what works for them. (Of course, they need to understand what is going on and
> documenting that can be a challenge.)

Fair. Our implementations might differ in this regard.


> rick
> 
>>
>> Ideally it would be more than just the CN.  We want to know both the
>> domain in which the peer has authority (e.g.  example.com) and the type
>> of authority (e.g.  serve-web-pages or proxy-file-access or
>> act-as-neilb).
>> I don't know internal details of certificates so I don't know if there
>> is some other field that can say "This peer is authorised to proxy file
>> access requests for all users in the given domain" or if we need a hack
>> like exporting to nfs-client.example.com.
>>
>> But if the admin has full control of what names to export to, it is
>> possible that the distinction doesn't matter.  I wouldn't want the
>> certificate used to authenticate my web server to have authority to
>> access all files on my NFS server just because the same domain name
>> applies to both.
>>
>> Thanks,
>> NeilBrown


-- 
Chuck Lever