BUG: NFSv4.2 does not handle context mounts correctly

[stephensmalley]

NFSv4.2 introduces support for file security labels. However, context mounts should still operate in the same manner as before, i.e. all files in the NFS filesystem should appear to be labeled with the context mount label on the client, and the NFS client filesystem should not try to set the context of any newly created files on the server. At present, we get mixed behavior with NFSv4.2: the top-level mount directory is labeled with the context mount, files that already existed on the server show up with the server file labels, newly created files on the client have their contexts set on the server to the context mount value. It is unclear whether this was ever correct for NFSv4.2, probably not.

$ cat nfs-bug.sh
#!/bin/sh
#Remove security_label if testing with an older nfs-utils, e.g. RHEL7.
cat > /etc/exports <<EOF
/home localhost(rw,no_root_squash,security_label)
EOF
exportfs -a
systemctl start nfs-server
mkdir -p /mnt/home
mount -t nfs -o vers=4.0,context=system_u:object_r:etc_t:s0 localhost:/home /mnt/home
echo "Under NFSv4.0:"
#Everything should be labeled with the context mount value.
ls -Z /mnt/home
#When we create a new file, it should appear to be labeled with the context mount value on the client.
touch /mnt/home/foo
ls -Z /mnt/home/foo
#But we should not try to set it on the server.
ls -Z /home/foo
rm /mnt/home/foo
umount /mnt/home
mount -t nfs -o vers=4.2,context=system_u:object_r:etc_t:s0 localhost:/home /mnt/home
echo "Under NFSv4.2:"
ls -Z /mnt/home
touch /mnt/home/foo
ls -Z /mnt/home/foo
ls -Z /home/foo
rm /home/foo
umount /mnt/home
rmdir /mnt/home
rm /etc/exports
exportfs -ua
systemctl stop nfs-server

$ sudo ./nfs-bug.sh
./nfs-bug.sh
Under NFSv4.0:
system_u:object_r:etc_t:s0 lost+found
system_u:object_r:etc_t:s0 sds
system_u:object_r:etc_t:s0 /mnt/home/foo
system_u:object_r:home_root_t:s0 /home/foo
Under NFSv4.2:
system_u:object_r:lost_found_t:s0 lost+found
unconfined_u:object_r:user_home_dir_t:s0 sds
system_u:object_r:etc_t:s0 /mnt/home/foo
system_u:object_r:etc_t:s0 /home/foo

[stephensmalley]

NB For 4.11 and later, this difference in behavior only manifests if exported with security_label; if not exported with security_label, then NFSv4.2 has the same behavior as NFSv4.0 wrt context mounts. However, regardless of how the filesystem is exported, clients should still have the ability to override the server's labels (e.g. if the client does not trust the server or uses a different policy) via context mounts.

[stephensmalley]

The way this is supposed to work is that the NFSv4 client code (nfs_set_sb_security) checks whether the server supports security labels, and if so, passes SECURITY_LSM_NATIVE_LABELS via kern_flags into security_sb_set_mnt_opts(). selinux_set_mnt_opts() internally handles context mount options and only sets SECURITY_LSM_NATIVE_LABELS in *set_kern_flags if there is no context mount. Then nfs_set_sb_security() checks those flags and if the flag is not set, then it clears NFS_CAP_SECURITY_LABEL from the server capabilities. That is supposed to disable all use of labels from the server or setting of labels on the server.

[stephensmalley]

Fixed by 0b4d345