On Thu, Jan 25, 2024 at 8:32 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > 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? To answer my own question, yes that's exactly what is happening. In every other hook that returns a non-zero default value, we have special handling in the security_() wrapper, but security_inode_getsecctx() just calls call_int_hook(), which treats any non-zero return as failure. So in kernels that enable SELinux+BPF-LSM with no BPF program attached to that hook, it will always return -EOPNOTSUPP and NFS and any other callers won't use the SELinux-provided attribute.
