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
