Introduction
The export policy for NFS and dual-protocol volumes on ANF contains some very important security settings. Not only do the selected values matter, the order in which they are applied can also be of importance. Let’s have a closer look.
Imagine the Finance department created a NFS volume without changing any of the export policy options, leaving everything default. The export policy would look like this:
Allow clients set to 0.0.0.0/0 means that any IP can connect to the volume with read & write permissions (specified by the access option). Root access set to on means that the root user has full access to the volume.
From a security best practices point of view, this is very likely not a config you want to run, since any client that can identify as the root user (uid=0) to the volume, will have full access. Examine the following picture.
The Finance VM NFS client, originating from IP 10.0.1.10, connects to the NFS volume, identifying as the root user. Full access is granted. The same is true for the HR VM NFS client, originating from IP 192.168.2.8. The passwords for the root users may very well be different, it doesn’t matter.
Configuring allowed clients
We’ll now configure the allowed clients to only include the Finance VM subnet, 10.0.1.0/24, removing the 0.0.0.0/0 entry, which automatically means all others networks are denied access.
By configuring this rule, we are now preventing the HR VM from connecting to the volume, since the session is originating from IP 192.168.2.8, which is not part of the allowed 10.0.1.0/24 subnet.
Configuring root access
We’ll now take additional steps to prevent the root user from accessing the volume. We do this by setting root access to off.
This is also know as root squash, meaning the root user is now mapped to the anonymous user, squashing (removing) all its permissions. The only thing the root user will be able to do is to mount the volume.
Root squash on deployment
You probably don’t want to configure root squash on volume deployment, since unless you set the Unix permissions to 0777, you won’t be able to access the volume. Let me explain.
We’ll create a NFS volume, leaving Unix permission default at 0770, meaning the owner (0770) and group (0770) will have read, write and execute permissions, whereas all others (0770) will have no permissions. We set root access to off.
We’ll now mount the volume. The mount command copied from the Azure Portal will like something like this.
sudo mount -t nfs -o rw,hard,rsize=262144,wsize=262144,vers=3,tcp 10.0.1.4:/finance finance
Note the first word, sudo, meaning the command will be executed as the root user. Inspect the mounted folder properties (finance in our example) by executing:
ls -hal
We were allowed to mount the volume, even though the root user is squashed. If we now try to either change the Unix permission or change ownership on the mount, we get an error.
So we are now stuck, the root user owns the mount, but its permissions are squashed, meaning we cannot add the proper permission for any other user. This could have been prevented, by setting the Unix permissions to 0777 on volume deployment.
Root squash on deployment with 0777 Unix permissions
To demonstrate further, we’ll now deploy a volume (finance2) with root access set to off and Unix permissions set to 0777.
We mount the volume and inspect the folder (finance2 in our example) by executing:
ls -hal
Next we’ll try to access folder finance (0770) and folder finance2 (0777), from user netapp.
Looking at the Unix permissions, user netapp identifies as others, meaning it does not have access to the finance folder (0770), but it does have access to the finance2 folder (0777).
This is not a config you would want to run in a production setup, since you probably don’t want everyone (others) to have access to your files and folders. On top of that, the root folder finance2 will still be owned by root, and this cannot be changed as long as root access is set to off.
Root squash after deployment with 0770 Unix permissions
We’ll now look at the best way to leverage root access in combination with Unix permissions. We’ll create yet another NFS volume (finance3) and leave all settings default, meaning Unix permissions set to 0770 and root access set to on.
We mount the volume and change the ownership and group to finance, by executing:
sudo chown finance:finance /finance3
Inspect the folder properties by running:
ls -hal
Now that the root user no longer owns the folder, we set root access to off in the export policy. Switch to root user and verify access to folder finance3 is denied.
sudo su
cd /finance3
Perfect! If we now were to add the allowed clients rule on top of that, the ideal situation would look something like this.
Thanks for reading!