On Wed, Jan 24, 2024 at 6:59 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > > > So the recent discussion regarding questionable setting of > > > isec->sclass in inode_setxattr and inode_setsecurity that was > > > introduced by the labeled NFS support patch made me wonder about the > > > state of the selinux-testsuite nfs tests. Trying to run those on a > > > current kernel fails even before getting to the tests themselves > > > because the attempt to relabel the files to test_file_t fails with > > > Operation not supported errors. Anyone know when this last worked? > > > > Looks like this has been reported for Fedora kernels here, > > https://bugzilla.redhat.com/show_bug.cgi?id=2257983 > > as a regression from 6.6.2 to 6.6.3 and later. > > Thanks for looking into this Stephen. Unfortunately I can't seem to > access that BZ right now (the FAS login page is hanging for me), has a > root cause been identified? So far the bug only contains info from the bug reporter, who narrowed it to a change between the 6.6.2 and 6.6.3 kernels but isn't sure what changes would be relevant there. Looking at the ChangeLog, the one that looks most likely to me is: commit 37dab33f754abd24b384d2b7b07349dc6611381b Author: Ondrej Mosnacek <omosnace@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks") Reported-by: Benjamin Coddington <bcodding@xxxxxxxxxx> Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> Signed-off-by: Paul Moore <paul@xxxxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> Could that be overriding the SELinux return value and thereby preventing encoding of the SELinux context in the NFS fattr structure returned by the server to the clients?
