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

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

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.

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.


> I imagine more flexible or complex rule logic might be desired in the
> future, and having that work land in ktls-utils would be nicer than having
> to do kernel work or handling various bits of certificate logic or reverse
> lookups in-kernel.

I agree that the kernel will have to be hands off (or, it will act as a
pipe between the user space pieces that actually handle the security
policy, if you will).


-- 
Chuck Lever