Bug 2257983

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.