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

[Benjamin Coddington <bcodding@redhat.com>]

On 27 May 2025, at 15:41, Chuck Lever wrote:

> On 5/27/25 3:18 PM, Benjamin Coddington wrote:
>> On 27 May 2025, at 11:05, Chuck Lever wrote:
>>
>>> On 5/25/25 8:09 PM, NeilBrown 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.
>>>>
>>>> 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.
>>>
>>> My thought is that, for each handshake, there would be two stages:
>>>
>>> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>>>    trust issue, so validating the certificate presented by the client is
>>>    the order of the day.
>>>
>>> 2. Does the NFS server authorize this client to access the export? This
>>>    is a check very similar to the hostname/netgroup/IP address check
>>>    that is done today, but it could be done just once at handshake time.
>>>    Match the certificate's fields against a per-export filter.
>>>
>>> I would take tlshd out of the picture for stage 2, and let NFSD make its
>>> own authorization decisions. Because an NFS client might be authorized
>>> to access some exports but not others.
>>>
>>> So:
>>>
>>> How does the server indicate to clients that yes, your cert is trusted,
>>> but no, you are not authorized to access this file system? I guess that
>>> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>>>
>>> What certificate fields should we implement matches for? CN is obvious.
>>> But what about SAN? Any others? I say start with only CN, but I'd like
>>> to think about ways to make it possible to match against other fields in
>>> the future.
>>>
>>> What would the administrative interface look like? Could be the machine
>>> name in /etc/exports, for instance:
>>>
>>> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>>>
>>> But I worry that will not be flexible enough. A more general filter
>>> mechanism might need something like the ini file format used to create
>>> CSRs.
>>
>> It might be useful to make the kernel's authorization based on mapping to a
>> keyword that tlshd passes back after the handshake, and keep the more
>> complicated logic of parsing certificate fields and using config files up in
>> ktls-utils userspace.
>
> I agree that the kernel can't do the filtering.
>
> But it's not possible that tlshd knows what export the client wants to
> access during the TLS handshake; no NFS traffic has been exchanged yet.
> Thus parsing per-export security settings during the handshake is not
> possible; it can happen only once tlshd passes the connected socket back
> to the kernel.
>
> And remember that ktls-utils is shared with NVMe and now QUIC as well.
> tlshd doesn't know anything about the upper layer protocols. Therefore
> adding NFS-specific authorization policy settings to ktls-utils is a
> layering violation.

Here tlshd doesn't need to know anything about the upper layer protocols, it
merely uses its mapping rules to match the certificate to a keyword it
passes back to the kernel in the successful handshake downcall.  The kernel
then can decide what that keyword means.  If not implemented in-kernel it
can merely be ignored.

> What makes the most sense is that the handshake succeeds, then NFSD
> permits the client to access any export resources that the server's
> per-export security policy allows, based on the client's cert.
>
>
>> I'm imagining something like this in /etc/exports:
>>
>> /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
>> /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
>>
>> .. and then tlshd would do the work to create a map of authorized
>> certificate identities mapped to a keyword, something like:
>>
>> CN=*                any
>> CN=*.nfsv4bat.org   users
>> SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob
>
> I think mountd is going to have to do that, somehow. It already knows
> about netgroups, for example, and this is very similar.

That sounds.. complicated.

Ben