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'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 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. > What about pre-shared keys? No certificate fields there. Same idea would work for those - list/map them to a keyword set on the export. Ben
