On 2/5/20 12:10 PM, Stephen Smalley wrote:
On 1/30/20 3:22 PM, Stephen Smalley wrote:
In addition to testing full NFS security labeling support,
make sure that context mounts continue to work independent
of whether the mount was exported with security_label, and
add a simple test of the default NFS file labeling.
With the previous changes, this completes addressing
https://github.com/SELinuxProject/selinux-testsuite/issues/32
Fixes: https://github.com/SELinuxProject/selinux-testsuite/issues/32
Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx>
---
v3 moves nfs.sh under tools/, updates README.md, and fixes nfs.sh for
the relocation. As before, these patches depend on the previous one
("testsuite: enable running over labeled NFS") in order to allow the
testsuite to pass on NFS mounts.
README.md | 5 ++++-
tools/nfs.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 1 deletion(-)
Both are now applied.
[...]
It would be good if we could get tools/nfs.sh running on kernels going
forward in addition to regular runs of selinux-testsuite.
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.
