On Wed, 14 May 2025, Jeff Layton wrote: > On Wed, 2025-05-14 at 21:43 +1000, NeilBrown wrote: > > On Wed, 14 May 2025, Jeff Layton wrote: > > > On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote: > > > > On Wed, 14 May 2025, NeilBrown wrote: > > > > > On Tue, 13 May 2025, Jeff Layton wrote: > > > > > > Back in the 80's someone thought it was a good idea to carve out a set > > > > > > of ports that only privileged users could use. When NFS was originally > > > > > > conceived, Sun made its server require that clients use low ports. > > > > > > Since Linux was following suit with Sun in those days, exportfs has > > > > > > always defaulted to requiring connections from low ports. > > > > > > > > > > > > These days, anyone can be root on their laptop, so limiting connections > > > > > > to low source ports is of little value. > > > > > > > > > > But who is going to export any filesystem to their laptop? > > > > > > > > > > > > > > > > > The point is that most NFS servers are run on networks where the admin > > > may not have 100% control over every host on the network. Once you're > > > that situation, relying on low port values for security is basically > > > worthless. > > > > "most" ?? Where did you get that statistic? > > > > Anecdotal experience. > > > "Some" are run on in-machine-room networks which are completely > > controlled, but which allow local users to log in to unprivileged > > accounts. In this case it makes perfect sense to rely on "privileged" > > ports to control access. If you silently change nfs-utils so that > > unprivileged users can have root-level access over NFS, then you are > > exposing the file server completely to anyone who can log in to an > > server in that local network. Are you sure you want to do that? > > > > These types of environments are vanishingly small these days. If you > have a network of any size, it is _really_ hard to prevent someone from > plugging a laptop or something else into a random network drop. In that case you should be disabling AUTH_UNIX, not disabling "secure". > > You can prevent that with 802.1x security, or something similar, but at > that point what is checking the source port going to give you? > > > > > > > > > > Make the default be "insecure" when creating exports. > > > > > > > > > > So you want to break lots of configurations that are working perfectly > > > > > well? > > > > > > > > Sorry - I was wrong. You aren't breaking working configurations, but > > > > you are removing a protection that people might be expecting. It might > > > > not be much protection, but it is not zero. > > > > > > > > > > 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. > > > > Not really. If any host is compromised on your network then this > protection goes out the window. If any host is compromised then all protections go out the window. Let's make "allsquash,anonuid=0" the default. > > The default should also always "just work". We have to balance that > with being secure. There is a reason we don't default to krb5, for > instance. In this case, the added security of checking low port values > by default is pretty worthless. I think we ought to err on the side of > usability. No. nonononono. The default should always be secure. Many things should be installed inactive and require explicit admin action to enable. A tool should "just work". A service should do nothing unless explicitly asked. > > Also, to be clear, this currently not even enforced in all situations > where TCP is used. iwarp travels over TCP, but using RDMA disables this > check. And presumably this has always been the case so there is no case of changing a default that people might be depending on. So they aren't particularly relevant. > > > 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). > > > > I don't see any benefit in that at all. If someone wants to do that, > they can get that via tracepoints. You reported that a configuration error was hard to debug. I suggested a way to make the configuration error more visible (and hence easier to debug). You cannot see the benefit....... clearly I didn't explain myself well - sorry. > > 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. > > > > Paying attention to source ports makes no sense at all. In the modern > age, all sorts of middleware boxes can change the source port on a > connection. It is essentially meaningless outside of a few tightly > controlled environments. Those environments can always enable "secure" > if they require it. But they are currently using the default in the knowledge that it is "secure" and you want to change the default for *everyone*. Sure - change the default for yourself if that is what you want. Update your script which generates /etc/exports or add some new option to /etc/nfs.conf, but don't impose your choice on everyone without asking them (and of course you cannot ask everyone). NeilBrown
