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
