RFE: Add tests for NFS security labeling support

[stephensmalley]

Add some tests of NFS security labeling support. This would ultimately include:

• testing that the file labels from the server are visible on the client and access is enforced correctly when the filesystem is exported with the security_label option (or by default prior to 4.11) and mounted using NFS v4.2. This could be done by running a subset of the already existing tests on a NFSv4.2 mount, ala: exportfs -orw,no_root_squash,security_label localhost:/path/to/selinux-testsuite; systemctl start nfs-server; mkdir -p /mnt/selinux-testsuite; mount -t nfs -o vers=4.2 localhost:/path/to/selinux-testsuite /mnt/selinux-testsuite; cd /mnt/selinux-testsuite; make test

NB: some of these tests currently fail, and this might be normal due to differences between NFS and local filesystems; we may need to select a subset of the tests to run or otherwise skip certain ones on NFS.

• testing that context mounts are properly honored, with and without security_label in exports, for NFS < 4.2 and NFS >= 4.2.

• testing that NFS file labeling and access under the default NFS file label.

[stephensmalley]

Failing tests: file/test (Wstat: 0 Tests: 16 Failed: 1) Failed test: 5 capable_file/test (Wstat: 0 Tests: 10 Failed: 4) Failed tests: 4, 6-8 capable_sys/test (Wstat: 0 Tests: 8 Failed: 1) Failed test: 1 overlay/test (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 121 tests but ran 0. mac_admin/test (Wstat: 0 Tests: 8 Failed: 1) Failed test: 5

file/test failure is due to lack of flock() support over NFS (correct, not a bug). capable_* failures are most likely due to NFS deferring setattr permission checking to the server, so not really a bug. overlay failure is presumably inability to use NFS as a lower/work dir for overlayfs, not a bug. mac_admin failure is due to getting unlabeled_t instead of UNDEFINED; NFS server won't export raw contexts to the client, not a bug.

[stephensmalley]

FWIW nfs labeling seems to be broken again, not sure how long it has been so. $ sudo exportfs -orw,no_root_squash,security_label localhost:$HOME $ sudo mkdir -p /mnt/$HOME $ sudo mount -t nfs -o vers=4.2 localhost:$HOME /mnt/$HOME $ ls -lZd $HOME /mnt/$HOME drwxr-xr-x. 579 sds sds unconfined_u:object_r:user_home_dir_t:s0 135168 Jan 23 10:23 /home/sds drwxr-xr-x. 579 sds sds system_u:object_r:nfs_t:s0 135168 Jan 23 10:23 /mnt//home/sds

[stephensmalley]

Hmm..seems like there has been a change in semantics for exports with security_label;if I export the top-level mount (e.g. /home in the case above, where /home is its own filesystem) with security_label, NFSv4.2 labeling is enabled but if I export a subdirectory (e.g. $HOME above) with security_label, it is not. Don't know what kernel version made this change since I don't run these tests regularly. Updated test script to exercise selinux-testsuite over NFSv4.2 with labeling is: !/bin/sh -e MOUNT=/home TESTDIR=/home/sds/selinux-testsuite exportfs -orw,no_root_squash,security_label localhost:$MOUNT systemctl start nfs-server mkdir -p /mnt/selinux-testsuite mount -t nfs -o vers=4.2 localhost:$TESTDIR /mnt/selinux-testsuite pushd /mnt/selinux-testsuite make test popd umount /mnt/selinux-testsuite exportfs -u localhost:$MOUNT systemctl stop nfs-server

[stephensmalley]

Also, after first being mounted, ls -Zd of the mountpoint shows unlabeled_t. It then appears to get refreshed at some point upon subsequent access to the correct label.

[stephensmalley]

A few potential enhancements and improvements that could still be made in the area of NFS testing:

1) There isn't yet a test that trying to mount the same NFS filesystem with two different sets of context mount options (or one with and one without context mount options) is rejected as expected.

2) There was an earlier bug where mounting a security_label exported NFS filesystem twice could clear the native labeling flags and thereby disable NFS security labeling support; this was fixed by kernel commit 3815a245b50124f0865415dcb606a034e97494d4. Adding a test to confirm that this behavior doesn't recur might be useful.

3) There was an earlier bug where context mounts of security_label exported NFS filesystems yielded mixed behavior with the top-level mount and newly created files appearing with the context mount value but pre-existing files appearing with the underlying xattr value; this was fixed by 0b4d3452b8b4a5309b4445b900e3cec022cca95a. My original version of nfs.sh actually would have caught this because it was testing the context of the nfs.sh script file itself within the context mount but I dropped it back to only checking the top-level mount directory when I moved tools/nfs.sh to avoid depending on a fixed location for it, so it won't be caught currently. We should probably change it back to testing the context of a pre-existing file within the mount; any file will do.

4) Ensuring that all of the tests/filesystem and tests/fs_filesystem tests that make sense for NFS are being run on the NFS mount itself and not just on an ext4 mount created by the test script.

5) We could have nfs.sh set a variable checked by tests/Makefile to skip any tests that are completely irrelevant from a filesystem security labeling perspective to minimize noise and duplication with regular runs of selinux-testsuite. In a certain sense, they all exercise filesystem security labeling in that they are depending on file labels but they aren't all testing that functionality per se. Deciding exactly which ones to include/exclude may not be entirely obvious though.

[stephensmalley]

This has been technically done for a long time and is finally enabled in automated testing. Huzzah!