On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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? Yes, I'm on it. I already have a candidate fix, but my kernel building infra is currently acting up, so it might take a while before I'm able to test & post it. -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
