4

Why is it considered insecure for an NFS export to allow connections originating from high ports? Compare the manual:

exportfs understands the following export options:

secure

This option requires that requests originate on an Internet port less than IPPORT_RESERVED (1024). This option is on by default. To turn it off, specify insecure.

https://linux.die.net/man/5/exports#content:~:text=General%20Options

Why does it matter which port the request is coming from? Shouldn't the client be free to choose whatever port they like?

The only benefit I see is in a company environment where no regular user has admin rights even on their own system. In this case, the secure setting prohibits using NFS clients not sanctioned by the IT administration. Is that the reason, or what am I overlooking?

bers
  • 200
  • 1
  • 9
  • See also [Why are the first 1024 ports restricted to the root user only? - Unix & Linux Stack Exchange](https://unix.stackexchange.com/questions/16564/why-are-the-first-1024-ports-restricted-to-the-root-user-only) – Sjoerd Mar 24 '21 at 08:48
  • @Sjoerd thanks! So my "company environment" hypothesis wasn't too far off. It seems to me the whole assumption breaks down as soon as I obtain local superuser privileges on a single system, but then it's the swiss cheese model, I guess. – bers Mar 24 '21 at 09:01

1 Answers1

5

NFS trusts the client to provide its user ID. If the client says "I am user ID 1234", then the server assumes it's being accessed by user 1234. (Root is often disabled though)

Ports below 1024 can only be used by root. Ports 1024 and above can be used by any user. If I create a socket on a port above 1023, I can just tell the NFS server that I'm you and then access your files.

If I have to create a socket on a port below 1024, then I can't do that unless I have root access to my local machine. In a corporate or school environment where I don't have root access to any of the machines, this may be considered a useful security check. Note that I can still impersonate you if I can connect my own machine to the network!

user253751
  • 3,885
  • 3
  • 19
  • 15
  • "Note that I can still impersonate you if I can connect my own machine to the network!" - There surely is a mechanism in NFS to trust only "domain-joined" (or whatever the Linux term for that is) to prevent that, right? – bers Mar 24 '21 at 11:04
  • @bers No clue. I haven't heard of one. If that did exist, they could just use it instead of the port check, anyway. Remember that NFS is a very old protocol, from back when security wasn't taken as seriously. – user253751 Mar 24 '21 at 11:06
  • "if that did exist, ..." - I think.they would still need the port check to make sure malicious users on trusted systems don't run untrusted clients spoofing other users' identities. – bers Mar 24 '21 at 18:46
  • You still would not trust the machine unconditionally. You would just trust that the machine if it is a) used by a trusted user (root, allowed to use priority ports) or b) used by an untrusted user who can use only trusted software (both cases covered by the port check). – bers Mar 24 '21 at 18:49
  • Or did I miss anything? – bers Mar 24 '21 at 18:49
  • @bers presumably in this system, the untrusted user wouldn't have the crypto keys that allow it to be domain-joined - otherwise he could plug his own machine into the network and use those keys as root on his own machine. – user253751 Mar 24 '21 at 20:15
  • But the non-privileged user on a domain-joined system could just start their own NFS client and spoof user ids, couldn't they? – bers Mar 25 '21 at 05:23
  • @bers I'm assuming it would be the NFS client that has the keys. The user's NFS client wouldn't have those keys. If the user could access the keys (but not the privileged port) they could still copy the keys to their own machine, and use a privileged port, so it wouldn't add security. – user253751 Mar 25 '21 at 12:54