* selinux-testsuite nfs tests?
@ 2024-01-24 18:42 Stephen Smalley
2024-01-24 20:13 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-01-24 18:42 UTC (permalink / raw
To: Paul Moore, Ondrej Mosnacek, SElinux list
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-24 18:42 selinux-testsuite nfs tests? Stephen Smalley
@ 2024-01-24 20:13 ` Stephen Smalley
2024-01-24 23:59 ` Paul Moore
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-01-24 20:13 UTC (permalink / raw
To: Paul Moore, Ondrej Mosnacek, SElinux list
On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
<stephen.smalley.work@gmail.com> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-24 20:13 ` Stephen Smalley
@ 2024-01-24 23:59 ` Paul Moore
2024-01-25 13:32 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2024-01-24 23:59 UTC (permalink / raw
To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list
On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> 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?
--
paul-moore.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-24 23:59 ` Paul Moore
@ 2024-01-25 13:32 ` Stephen Smalley
2024-01-25 14:25 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-01-25 13:32 UTC (permalink / raw
To: Paul Moore; +Cc: Ondrej Mosnacek, SElinux list
On Wed, Jan 24, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> 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@redhat.com>
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@vger.kernel.org
Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks")
Reported-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 13:32 ` Stephen Smalley
@ 2024-01-25 14:25 ` Stephen Smalley
2024-01-25 14:52 ` Paul Moore
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-01-25 14:25 UTC (permalink / raw
To: Paul Moore; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 8:32 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Jan 24, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> 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@redhat.com>
> 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@vger.kernel.org
> Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks")
> Reported-by: Benjamin Coddington <bcodding@redhat.com>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 14:25 ` Stephen Smalley
@ 2024-01-25 14:52 ` Paul Moore
2024-01-25 15:14 ` Ondrej Mosnacek
0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2024-01-25 14:52 UTC (permalink / raw
To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 9:25 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Jan 25, 2024 at 8:32 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Wed, Jan 24, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> 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@redhat.com>
> > 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@vger.kernel.org
> > Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks")
> > Reported-by: Benjamin Coddington <bcodding@redhat.com>
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 14:52 ` Paul Moore
@ 2024-01-25 15:14 ` Ondrej Mosnacek
2024-01-25 15:16 ` Paul Moore
0 siblings, 1 reply; 17+ messages in thread
From: Ondrej Mosnacek @ 2024-01-25 15:14 UTC (permalink / raw
To: Paul Moore; +Cc: Stephen Smalley, SElinux list
On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jan 25, 2024 at 9:25 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Thu, Jan 25, 2024 at 8:32 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Wed, Jan 24, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Wed, Jan 24, 2024 at 3:13 PM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > On Wed, Jan 24, 2024 at 1:42 PM Stephen Smalley
> > > > > <stephen.smalley.work@gmail.com> 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@redhat.com>
> > > 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@vger.kernel.org
> > > Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks")
> > > Reported-by: Benjamin Coddington <bcodding@redhat.com>
> > > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 15:14 ` Ondrej Mosnacek
@ 2024-01-25 15:16 ` Paul Moore
2024-01-25 15:49 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2024-01-25 15:16 UTC (permalink / raw
To: Ondrej Mosnacek; +Cc: Stephen Smalley, SElinux list
On Thu, Jan 25, 2024 at 10:15 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > 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.
Great, no worries if it takes a little longer, I just wanted to see if
you were able to put together a fix or if I needed to do it.
--
paul-moore.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 15:16 ` Paul Moore
@ 2024-01-25 15:49 ` Stephen Smalley
2024-01-25 15:58 ` Paul Moore
2024-01-25 15:59 ` Stephen Smalley
0 siblings, 2 replies; 17+ messages in thread
From: Stephen Smalley @ 2024-01-25 15:49 UTC (permalink / raw
To: Paul Moore; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 10:16 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jan 25, 2024 at 10:15 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > 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.
>
> Great, no worries if it takes a little longer, I just wanted to see if
> you were able to put together a fix or if I needed to do it.
FYSA, reverting that change does restore basic labeling of NFS files
but ./tools/nfs.sh is still failing later, or rather hanging during
the Unix socket tests on a NFS mount. Not sure why yet.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 15:49 ` Stephen Smalley
@ 2024-01-25 15:58 ` Paul Moore
2024-01-25 15:59 ` Stephen Smalley
1 sibling, 0 replies; 17+ messages in thread
From: Paul Moore @ 2024-01-25 15:58 UTC (permalink / raw
To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 10:50 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Jan 25, 2024 at 10:16 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Jan 25, 2024 at 10:15 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > 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.
> >
> > Great, no worries if it takes a little longer, I just wanted to see if
> > you were able to put together a fix or if I needed to do it.
>
> FYSA ...
I'll admit to having to google that ;)
> ... reverting that change does restore basic labeling of NFS files
> but ./tools/nfs.sh is still failing later, or rather hanging during
> the Unix socket tests on a NFS mount. Not sure why yet.
Since we know what the problem is, and while we haven't seen it yet, I
think we mostly know what Ondrej's patch is going to look like
(assuming no testing surprises), I don't see a need to do a revert.
Independent of that, we should figure out if we need to do any
additional work to restore labeled NFS.
--
paul-moore.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 15:49 ` Stephen Smalley
2024-01-25 15:58 ` Paul Moore
@ 2024-01-25 15:59 ` Stephen Smalley
2024-01-25 16:08 ` Paul Moore
1 sibling, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-01-25 15:59 UTC (permalink / raw
To: Paul Moore; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 10:49 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Jan 25, 2024 at 10:16 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Thu, Jan 25, 2024 at 10:15 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Thu, Jan 25, 2024 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > 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.
> >
> > Great, no worries if it takes a little longer, I just wanted to see if
> > you were able to put together a fix or if I needed to do it.
>
> FYSA, reverting that change does restore basic labeling of NFS files
> but ./tools/nfs.sh is still failing later, or rather hanging during
> the Unix socket tests on a NFS mount. Not sure why yet.
So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
or has it been wired up into the automated testing by anyone? If not
and if we can get it back to a clean state, that would be good to do.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 15:59 ` Stephen Smalley
@ 2024-01-25 16:08 ` Paul Moore
2024-01-26 10:11 ` Ondrej Mosnacek
0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2024-01-25 16:08 UTC (permalink / raw
To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list
On Thu, Jan 25, 2024 at 10:59 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
> or has it been wired up into the automated testing by anyone? If not
> and if we can get it back to a clean state, that would be good to do.
I am not as part of my kernel-secnext testing, I should, but I haven't
had the time to configure that as part of the test run. Building and
testing on Debian in addition to Fedora is still higher on my
kernel-secnext todo list, and I haven't made much progress there.
I believe the IBM/RH folks are doing regular testing, perhaps they
have something in place?
--
paul-moore.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-25 16:08 ` Paul Moore
@ 2024-01-26 10:11 ` Ondrej Mosnacek
2024-05-02 19:18 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Ondrej Mosnacek @ 2024-01-26 10:11 UTC (permalink / raw
To: Paul Moore; +Cc: Stephen Smalley, SElinux list
On Thu, Jan 25, 2024 at 5:09 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jan 25, 2024 at 10:59 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
> > or has it been wired up into the automated testing by anyone? If not
> > and if we can get it back to a clean state, that would be good to do.
>
> I am not as part of my kernel-secnext testing, I should, but I haven't
> had the time to configure that as part of the test run. Building and
> testing on Debian in addition to Fedora is still higher on my
> kernel-secnext todo list, and I haven't made much progress there.
>
> I believe the IBM/RH folks are doing regular testing, perhaps they
> have something in place?
We don't currently run the NFS-backed selinux-testsuite,
unfortunately. Looking at my unmerged branches, I can see I tried to
add it over 2 years ago, but the note I had left for myself says
"doesn't work yet due to NFS bug", so presumably it wasn't passing
even back then.
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-01-26 10:11 ` Ondrej Mosnacek
@ 2024-05-02 19:18 ` Stephen Smalley
2024-05-02 19:50 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-05-02 19:18 UTC (permalink / raw
To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list
On Fri, Jan 26, 2024 at 5:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Thu, Jan 25, 2024 at 5:09 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Thu, Jan 25, 2024 at 10:59 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
> > > or has it been wired up into the automated testing by anyone? If not
> > > and if we can get it back to a clean state, that would be good to do.
> >
> > I am not as part of my kernel-secnext testing, I should, but I haven't
> > had the time to configure that as part of the test run. Building and
> > testing on Debian in addition to Fedora is still higher on my
> > kernel-secnext todo list, and I haven't made much progress there.
> >
> > I believe the IBM/RH folks are doing regular testing, perhaps they
> > have something in place?
>
> We don't currently run the NFS-backed selinux-testsuite,
> unfortunately. Looking at my unmerged branches, I can see I tried to
> add it over 2 years ago, but the note I had left for myself says
> "doesn't work yet due to NFS bug", so presumably it wasn't passing
> even back then.
I finally tracked down the source of one bug (not setting the label on
new files properly) and sent a patch for that. Several of the other
failures were introduced by the use of fifos for synchronization;
apparently fifos on NFS aren't expected to work and hence unix_socket
and other tests that rely on those won't work there.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-05-02 19:18 ` Stephen Smalley
@ 2024-05-02 19:50 ` Stephen Smalley
2024-05-02 19:54 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-05-02 19:50 UTC (permalink / raw
To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list
On Thu, May 2, 2024 at 3:18 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, Jan 26, 2024 at 5:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > On Thu, Jan 25, 2024 at 5:09 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Thu, Jan 25, 2024 at 10:59 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
> > > > or has it been wired up into the automated testing by anyone? If not
> > > > and if we can get it back to a clean state, that would be good to do.
> > >
> > > I am not as part of my kernel-secnext testing, I should, but I haven't
> > > had the time to configure that as part of the test run. Building and
> > > testing on Debian in addition to Fedora is still higher on my
> > > kernel-secnext todo list, and I haven't made much progress there.
> > >
> > > I believe the IBM/RH folks are doing regular testing, perhaps they
> > > have something in place?
> >
> > We don't currently run the NFS-backed selinux-testsuite,
> > unfortunately. Looking at my unmerged branches, I can see I tried to
> > add it over 2 years ago, but the note I had left for myself says
> > "doesn't work yet due to NFS bug", so presumably it wasn't passing
> > even back then.
>
> I finally tracked down the source of one bug (not setting the label on
> new files properly) and sent a patch for that. Several of the other
> failures were introduced by the use of fifos for synchronization;
> apparently fifos on NFS aren't expected to work and hence unix_socket
> and other tests that rely on those won't work there.
Actually, it seems that I misinterpreted earlier test results. With my
patch applied on top of nfs-next, the entire ./tools/nfs.sh run
passes, including unix_socket and friends. Huzzah! Can we get this
wired up into automated regression testing to keep it that way?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-05-02 19:50 ` Stephen Smalley
@ 2024-05-02 19:54 ` Stephen Smalley
2024-05-03 1:06 ` Paul Moore
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2024-05-02 19:54 UTC (permalink / raw
To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list
On Thu, May 2, 2024 at 3:50 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, May 2, 2024 at 3:18 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Fri, Jan 26, 2024 at 5:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > On Thu, Jan 25, 2024 at 5:09 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Thu, Jan 25, 2024 at 10:59 AM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > So as a side-bar is anyone running ./tools/nfs.sh on a regular basis
> > > > > or has it been wired up into the automated testing by anyone? If not
> > > > > and if we can get it back to a clean state, that would be good to do.
> > > >
> > > > I am not as part of my kernel-secnext testing, I should, but I haven't
> > > > had the time to configure that as part of the test run. Building and
> > > > testing on Debian in addition to Fedora is still higher on my
> > > > kernel-secnext todo list, and I haven't made much progress there.
> > > >
> > > > I believe the IBM/RH folks are doing regular testing, perhaps they
> > > > have something in place?
> > >
> > > We don't currently run the NFS-backed selinux-testsuite,
> > > unfortunately. Looking at my unmerged branches, I can see I tried to
> > > add it over 2 years ago, but the note I had left for myself says
> > > "doesn't work yet due to NFS bug", so presumably it wasn't passing
> > > even back then.
> >
> > I finally tracked down the source of one bug (not setting the label on
> > new files properly) and sent a patch for that. Several of the other
> > failures were introduced by the use of fifos for synchronization;
> > apparently fifos on NFS aren't expected to work and hence unix_socket
> > and other tests that rely on those won't work there.
>
> Actually, it seems that I misinterpreted earlier test results. With my
> patch applied on top of nfs-next, the entire ./tools/nfs.sh run
> passes, including unix_socket and friends. Huzzah! Can we get this
> wired up into automated regression testing to keep it that way?
Sorry, sent too soon. It does pass running the entire
selinux-testsuite on a NFS mount with security labeling enabled, but
then starts hitting some failures during the later context mount
tests. Likely bears further investigation.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: selinux-testsuite nfs tests?
2024-05-02 19:54 ` Stephen Smalley
@ 2024-05-03 1:06 ` Paul Moore
0 siblings, 0 replies; 17+ messages in thread
From: Paul Moore @ 2024-05-03 1:06 UTC (permalink / raw
To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list
On Thu, May 2, 2024 at 3:54 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> Sorry, sent too soon. It does pass running the entire
> selinux-testsuite on a NFS mount with security labeling enabled, but
> then starts hitting some failures during the later context mount
> tests. Likely bears further investigation.
Still a good step forward, thanks Stephen.
FWIW, once we get this working, I'll see about adding a test run on a NFS mount.
--
paul-moore.com
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2024-05-03 1:06 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-24 18:42 selinux-testsuite nfs tests? Stephen Smalley
2024-01-24 20:13 ` Stephen Smalley
2024-01-24 23:59 ` Paul Moore
2024-01-25 13:32 ` Stephen Smalley
2024-01-25 14:25 ` Stephen Smalley
2024-01-25 14:52 ` Paul Moore
2024-01-25 15:14 ` Ondrej Mosnacek
2024-01-25 15:16 ` Paul Moore
2024-01-25 15:49 ` Stephen Smalley
2024-01-25 15:58 ` Paul Moore
2024-01-25 15:59 ` Stephen Smalley
2024-01-25 16:08 ` Paul Moore
2024-01-26 10:11 ` Ondrej Mosnacek
2024-05-02 19:18 ` Stephen Smalley
2024-05-02 19:50 ` Stephen Smalley
2024-05-02 19:54 ` Stephen Smalley
2024-05-03 1:06 ` Paul Moore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).