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

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

On 5/27/25 12:29 PM, Rick Macklem wrote:
> On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@oracle.com> 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.
> Just fyi, here's an example where filtering on the DNS or IP field in the
> SAN (SubjectAltName) could improve security..
> (Dusting off my CS sysadmin hat.)
> 
> Suppose I had a file system where student grades and exam questions
> were stored.
> The mount was restricted to faculty offices, where their machines had fixed
> well known IP addresses and FQDNs assigned.
> However, as it was for my case, the building their offices were in also had
> student labs and the building was assigned a subnet by the campus
> networking folk.
> --> As such, a student could easily come in off hours (when the faculty were not
>      around and, as such, had their office computers shut down) and
> plug into the
>      subnet (they just had to find an RJ45 jack somewhere that they
> could access).
>      --> They could then set their laptop up with the same IP address
> as a faculty
>            member's office computer and defeat ordinary /etc/exports
> filtering based
>            on client IP address.
> 
> However, these students would not have the X.509 cert. with a DNS or IP field
> set to the correct address in it. (They might have a valid cert. so
> their laptop can
> mount the file systems students have coursework assignments on, but it would
> not have the DNS or IP of a faculty member's office computer.)
> --> This additional filtering would stop them from accessing the
> marks/exam question
>       file system (or at least make it a lot harder for them to do so).
> 
> As already discussed, there is a tradeoff between using DNS or IP. (I'll admit
> FreeBSD doesn't currently support the IP case, but it probably should.)

To be clear, there is a marked difference between relying on reverse DNS
queries versus relying on a DNS hostname or IP address contained in a
client certificate's SAN field. DNS queries are untrustworthy, but
fields in a certificate (once its trust chain has been validated) are OK
to use, IMO.

But I would like NFSD's administrative interface to be unambiguous about
which DNS/IP information is being matched against.


> rick
> 
>>
>> 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.
>>
>>
>> What about pre-shared keys? No certificate fields there.
>>
>>
>> --
>> Chuck Lever


-- 
Chuck Lever