I have used option security_label in /etc/exports since many years. It ensures that nfs clients present the same selinux file context labels as the exported file system have. I have updated our nfs server to Fedora 39. Now selinux file context labels are nfs_t instead of the labels that are on the exported file system. I use the same exports configuration as in Fedora 35 and Fedora 37. I didn't find anything on internet, bugzilla, ask.fedora, manpages, etc. about a change about this. I also checked the fedora kernel config file, the compile option is still enabled. root@myserver:~# grep -i security_label /lib/modules/6.6.9-200.fc39.x86_64/config CONFIG_NFS_V4_SECURITY_LABEL=y CONFIG_NFSD_V4_SECURITY_LABEL=y CONFIG_CEPH_FS_SECURITY_LABEL=y I analyzed network traffic between a Fedora 39 nfs client and nfs servers running Fedora 39, Fedora 38, Fedora 37, Fedora 35, using tcpdump and wireshark. NFS packages from Fedora 35 and 37 have in opcode GETATTR an subfield Attr mask[2], which contains reco_attr: Security_label. This subfield doesn't exist in nfs packages from nfs servers running Fedora 38 and 39 (they only have Attr mask[0] and Attr mask[1]). Is this a bug, is this intended, and how can I get the right selinux labels back on nfs clients? There was a similar bug in Fedora 26, see bug 1478135. But in the meantime it works fine. I'm not sure if the bug is in nfs-tools or the kernel, or another package. Reproducible: Always
Created attachment 2008364 [details] Screenshot of wireshark from Fedora 35 nfs network package opcode GETATTR Attr mask[2]
Hi Edgar, glad you posted this. I've observed the same on my own machine after upgrading from Fedora 38 to Fedora 39 - no selinux contexts get served up and everything comes over as 'nfs_t' on my kerberized home mount. /etc/exports has not been touched in ages
I have done more tests. Mounting a filesystem exported by a nfs server running Fedora 35, Fedora 37, Fedora 38 on a nfs client running Fedora 39 still works as expected: SELinux context labels are the same on nfs server and nfs client. Fedora recognizes the SELinux labels, mount option "seclabel" may be used, but it it always automatically mounted with option "seclabel". Mounting a filesystem exported by a nfs server running Fedora 39 on a nfs client running Fedora 35, Fedora 37, Fedora 38, Fedora 39 does not work as expected: All SELinux context labels on the nfs client are type nfs_t. Mount option "seclabel" is ignored. "mount" listing does not include option "seclabel". So it seems to me that Fedora 39 nfs client can handle SELinux context labels, but Fedora 39 nfs server does not export / send SELinux context labels to the nfs client. Currently running kernel-6.6.12-200.fc39.x86_64 nfs-utils-2.6.4-0.rc3.fc39.x86_64 .
I also tried kernel-6.7.1-200.fc39.x86_64, but it doesn't change the behavior.
Another info: I had a virtual machine running Fedora 38, last booted at Fri Aug 25 16:31 with kernel 6.4.11-200.fc38. This was the machine I had used as test nfs server for Fedora 38, as listed above. SELinux labels worked fine at this stage. Now I have applied all outstanding updates and have rebooted it with kernel 6.6.12-100.fc38. Now it shows the same wrong behavior as Fedora 39. So it seams that some updated packages between Aug 25 2023 and now has caused the change of behavior. But currently I don't know which packages it is.
I have rebooted the vm noticed above with the old kernel 6.4.11-200.fc38. This brought the old, right behavior back, the SELinux labels from the nfs client are the same as on the nfs server. So it seams to me that some change in kernel between 6.4.11-200 and 6.6.12-100 causes the problem. So changing the component to kernel.
I did more tests, installing and booting several kernel versions from Fedora 38 and 39 for the nfs server. kernel-6.5.12-200.fc38.x86_64 works, uses seclabel kernel-6.6.2-101.fc38.x86_64 works, uses seclabel kernel-6.6.3-100.fc38.x86_64 doesn't work, ignores seclabel kernel-6.6.4-100.fc38.x86_64 doesn't work, ignores seclabel kernel-6.6.6-100.fc38.x86_64 doesn't work, ignores seclabel kernel-6.6.12-100.fc38.x86_64 doesn't work, ignores seclabel kernel-6.6.1-300.fc39.x86_64 works, uses seclabel kernel-6.6.2-201.fc39.x86_64 works, uses seclabel kernel-6.6.3-200.fc39.x86_64 doesn't work, ignores seclabel kernel-6.6.11-200.fc39.x86_64 doesn't work, ignores seclabel kernel-6.6.12-200.fc39.x86_64 doesn't work, ignores seclabel So, it seams to me that a change from kernel version 6.6.2 to 6.6.3 has introduced this nfs SELinux problem.
I tried also the following kernel versions on the nfs server, but the problem still exists. kernel-6.7.1-200.fc39.x86_64 kernel-6.8.0-0.rc1.20240124git615d30064886.13.fc39.x86_64 I also re-checked kernel 6.6.2 and 6.6.3, and confirm that kernel 6.6.3 introduces the problem with nfs_t instead of the real SELinux file context. Anything else on the nfs server except the running kernel version is the same. I have read the changelog [1] of kernel 6.6.3, but I don't see something that may have removed the security_label from nfs. Maybe someone with more kernel source knowledge recognizes the change that causes the problem. [1] https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.3
I haven't yet bisected but looking at that ChangeLog the most likely candidate appears to be: commit 37dab33f754abd24b384d2b7b07349dc6611381b Author: Ondrej Mosnacek <omosnace> Date: Tue Oct 31 13:32:07 2023 +0100 lsm: fix default return value for inode_getsecctx commit b36995b8609a5a8fe5cf259a1ee768fcaed919f8 upstream. -EOPNOTSUPP is the return value that implements a "no-op" hook, not 0. Without this fix having only the BPF LSM enabled (with no programs attached) can cause uninitialized variable reads in nfsd4_encode_fattr(), because the BPF hook returns 0 without touching the 'ctxlen' variable and the corresponding 'contextlen' variable in nfsd4_encode_fattr() remains uninitialized, yet being treated as valid based on the 0 return value. Cc: stable.org Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks") Reported-by: Benjamin Coddington <bcodding> Signed-off-by: Ondrej Mosnacek <omosnace> Signed-off-by: Paul Moore <paul> Signed-off-by: Greg Kroah-Hartman <gregkh>
Indeed it was that commit that broke it. I posted a fix here: https://lore.kernel.org/linux-security-module/20240126104403.1040692-1-omosnace@redhat.com/
Ondrej, Stephen, many thanks for your help and the fix, and for including it in upstream kernel. Now I have installed kernel 6.7.6. It solves the problem! Will you include it in bodhi for this kernel, so this bug will be auto-closed?
(In reply to Edgar Hoch from comment #11) > Now I have installed kernel 6.7.6. It solves the problem! > > Will you include it in bodhi for this kernel, so this bug will be > auto-closed? I can't do that, since I didn't create the update. Justin, could you please add this bug to https://bodhi.fedoraproject.org/updates/FEDORA-2024-d16d94b00d?
FEDORA-2024-d16d94b00d (kernel-6.7.6-200.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-d16d94b00d
Thanks, Justin! Clearing the needinfo.
FEDORA-2024-d16d94b00d (kernel-6.7.6-200.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.