On 5/14/25 7:43 AM, NeilBrown wrote: > On Wed, 14 May 2025, Jeff Layton wrote: >> On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote: >> True. Anyone relying on this "protection" is fooling themselves though. > > As above: in some circumstances with physically secure networks > (entirely in a locked room, or entire in a virtualisation host, or a > VPN) it makes perfect sense. On a physically secure network where all the hosts are also known to be secure, source port checking is wholly superfluous. It makes no sense there. >>>> I don't see any really motivation for this change. Could you provide it >>>> please? >>> >>> Or to put it another way: who benefits? >>> >> >> Anyone running NFS clients behind NAT? > > Maybe that should have been in the commit message? Agreed, the commit message should have more beef (sorry, vegetarians). The commit message should also mention that NFS clients frequently exhaust their privileged source port range, causing new mount operations to fail sporadically. This is a well-documented problem and the main reason we started moving Kerberized mounts to ephemeral ports. Generally that's a situation that is sticky for a couple of minutes while TCP sockets proceed through TIME_WAIT until the source port can be re-used by another connection. >> The main discussion came about when we were testing against a >> hammerspace deployment. They were using knfsd as their DS's, and had >> forgotten to add "insecure" to the export options. When the (NAT'ed) >> client tried to talk to the DS's, it got back NFSERR3_PERM because of >> this. It took a little while to ascertain the cause. > > "Change default to fix configuration problem"....??? > The default must always be the more secure. "fail safe". Sure, but this option, although it's name is "secure", offers very little real security. So we are actively promoting a mythological level of security here, and that is a Bad Thing (tm). > If we want to make this configuration problem more easy to detect, maybe > we should log unprivileged port access (beyond the few requests for > which it can make sense). Logging this would be a potential DoS: A simple user space program could connect to 2049 repeatedly and fill the server's log. But again, not worth the trouble: desktop file browsers connect from ephemeral ports. Why log those harmless accesses? >> Note that Solaris' NFS server stopped checking source ports many years >> ago. We're only doing this now because we followed suit from how they >> behaved in the 90s and never changed it. > > I wonder why Sun went out of business..... It certainly wasn't due to the Solaris NFS server's port checking behavior. This is a red herring. I see very few CVEs or other security advisories that describe the Solaris NFS server behavior as an active exploit. That suggests to me that source port checking is not valuable as a security mechanism. > Ignoring source ports makes no sense at all unless you enforce some other > authentication, like krb5 or TLS, or unless you *know* that there are no > unprivileged processes running on any client machines. I'd be in favor of, first: * exportfs emitting a message when neither "secure" nor "insecure" is specified for one or more exports * Updating the description of "secure" in exports(8) to explain that this option provides little to no security, and strongly recommending the deployment of cryptographic security mechanisms (as described in the "RPCSEC_GSS security" section Then later change the default to "insecure". -- Chuck Lever
