As noted in the introduction, folders shared via NFS act as if they had been made available to other computers via an external hard drive. For this reason, similar concepts are used for access permissions as well:
To guarantee secure operation, it is a necessary prerequisite to synchronize the user and group accounts between all computers which are part of the network sharing data via NFS.
In very small networks, synchronizing the account data could be done manually if no better solution is possible. The typical solution however is to establish a network-wide directory service for this purpose. A directory service is a common database shared in the network to store all account information. With the exception of accounts used for maintenance purposes, local accounts stored on each computer should no longer be used. All computers should only use accounts from the single central directory, so they are synchronized automatically.
In base configuration, macOS supports the directory service technologies
Note: The support of general LDAP servers of third-party vendors varies between operating system versions. Apple no longer advertises these features officially.
Binding a macOS computer to a running directory service is done with the application Directory Utility available in the folder /System/Library/CoreServices/Applications. Setting up a directory service is beyond the scope of this manual. For this reason, it won’t be described further.
When using NFS version 4, a feature known as ID mapping can be used to map user and group identifications between client and server. This also requires utilization of a directory service. In addition, an NFSv4 Domain Name has to be set. This domain name can be configured in the operating system by entering the following command in Terminal:
sudo dscl . -create Config/NFSv4Domain RealName EXAMPLE.COM
The part EXAMPLE.COM has to be replaced by the actual name of the NFSv4 domain.
Some versions of macOS are known not to support this feature very reliably. Please see the Release Notes of NFS Manager and technical support documents of Apple (if available) for further information.
Perhaps not all computers in your network are capable of using a common directory service. To avoid security risks, all computers which are not explicitly legitimated to connect to a server should not be granted access. For this reason, NFS supports the following restrictions which can be configured separately for each share:
The aforementioned methods to deny access to an NFS share are not very safe: If the network is open, e.g. accessible via an unprotected WLAN, or if there are Ethernet sockets which are not locked or monitored otherwise, attackers could connect to the network with their own computers. They could then take over the IP address of a legitimate computer, hereby circumventing the access restrictions.
To close such security holes, macOS can protect an NFS share using Kerberos technology. Kerberos is a complex authentication method for the mutual safe identification of services, devices and users, based on encryption technology. The security level reached by Kerberos is usually higher than that of using protection with classic passwords. Passwords are replaced by tap-proof, tamper-proof, and self-expiring key sequences which are called Kerberos tickets.
Because Kerberos tickets can be sent automatically through the network without risks, a Single Sign-On is possible: A user logs in only once at a central service in the network. After the user has been identified, all services on all computers this user has access to are unlocked automatically without any further login procedure necessary. The access permissions will be revoked when either the ticket has expired (in macOS typically 10 hours after initial login) or when the user deactivates the ticket explicitly.
The Kerberos technique is not limited to users only, but also allows devices and services to identify each other safely. macOS can associate one or more of the following security requirements with an NFS share:
To use Kerberos, it has to be configured in the network first. The following prerequisites are necessary:
Configuring Kerberos is beyond the scope of this manual and is not described further.
If your network has connections to other networks, for example the Internet, accessing NFS servers from the foreign network can be blocked using a packet filter firewall. After the packet filter has been configured not to pass NFS network traffic, access is no longer possible from a network beyond the filter.
Each share can also be setup for read-only mode and for user account mapping:
In addition to classic POSIX permissions, macOS also allows to define permissions using Access Control Lists (ACLs), compatible with Microsoft® Windows and the POSIX.1e draft. However, ACLs can only be used with NFS version 4. When using NFSv2 or NFSv3, please consider the following:
Some security features of the NFS protocol standard are based on definitions which exact list of computers should have permission to access files shared on an NFS server. It is convenient (not only for security aspects) to refer to the different computers via host names, not IP addresses. The use of host names requires that the Domain Name Service (DNS) which maps names to addresses and vice versa has been setup correctly for your TCP/IP network. In small private networks, the DNS is usually running on an Internet home router. In professional networks, the DNS is usually hosted on a dedicated server computer. If macOS detects that no valid DNS is available in your network, it will automatically switch to using Bonjour names (ending with “.local”) as a workaround. Using Bonjour names for access definitions of NFS networking can be a security problem however, because users could try to rename their own computers to disguise as a different one, and hereby automatically reconfigure the network to circumvent security restrictions.
NFS Manager can perform a simple check to see if DNS is set up correctly in your network, using the current computer as the test object. It will also detect if host names appear to be based on Bonjour only which could be a security-critical network configuration error. To run the test, do the following:
The check only tests if DNS is responding correctly and whether host names might be administered by Bonjour only. It does not perform a security check on the DNS server to see at which trust level server responses should be interpreted.