On Thu, Jan 25, 2024 at 9:25 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > 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. Thanks Stephen. I will admit that it is slightly amusing that a patch intending to fix NFS ends up breaking NFS; clearly some additional testing was needed here. Ondrej, are you able to post a fix for this? -- paul-moore.com
