Re: [PATCH 0/2] selinux-testsuite: Use native filesystem for tests

From: Richard Haines <richard_c_haines@btinternet.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Scott Mayhew <smayhew@redhat.com>
Subject: Re: [PATCH 0/2] selinux-testsuite: Use native filesystem for tests
Date: Fri, 13 Mar 2020 18:27:18 +0000	[thread overview]
Message-ID: <329bd598b85ae23aa67272cebaa1e9f3e7e42f93.camel@btinternet.com> (raw)
In-Reply-To: <CAEjxPJ4NE+V67GTyiAaBb3ZX_mc5kiCOnL9pDotLb2m9z-nLWg@mail.gmail.com>

On Fri, 2020-03-13 at 14:22 -0400, Stephen Smalley wrote:
> On Fri, Mar 13, 2020 at 2:18 PM Richard Haines
> <richard_c_haines@btinternet.com> wrote:
> > On Fri, 2020-03-13 at 13:21 -0400, Stephen Smalley wrote:
> > > On Fri, Mar 13, 2020 at 12:04 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > On Fri, Mar 13, 2020 at 11:47 AM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > On Thu, Mar 12, 2020 at 7:37 AM Richard Haines
> > > > > <richard_c_haines@btinternet.com> wrote:
> > > > > > If you test on the selinux-next kernel (that has the XFS
> > > > > > patch
> > > > > > [1]) with
> > > > > > the "NFS: Ensure security label is set for root inode"
> > > > > > patch
> > > > > > [2], then all
> > > > > > tests should pass. Anything else will give varying amounts
> > > > > > of
> > > > > > fails.
> > > > > > 
> > > > > > The filesystem types tested are: ext4, xfs, vfat and nfs4.
> > > > > > 
> > > > > > I've revamped the nfs.sh to handle tests that require
> > > > > > specific
> > > > > > mount
> > > > > > options, these plus many more are now in
> > > > > > tests/nfs_filesystem.
> > > > > > This only
> > > > > > gets run by nfs.sh.
> > > > > > 
> > > > > > There are two minor workarounds involving multiple mounts
> > > > > > returning EBUSY.
> > > > > > These are either bugs or features.
> > > > > > 
> > > > > > [1]
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/patch/security/selinux?id=e4cfa05e9bfe286457082477b32ecd17737bdbce
> > > > > > [2]
> > > > > > https://lore.kernel.org/selinux/20200303225837.1557210-1-smayhew@redhat.com/
> > > > > 
> > > > > Still failing for me:
> > > > > filesystem/test ............. 13/27 Failed mount(2):
> > > > > Permission
> > > > > denied
> > > > > filesystem/test ............. 18/27
> > > > 
> > > > Sorry, that's on me.  Wrong kernel.  Will retry...
> > > 
> > > Same failures with the right kernel.  If I am reading it
> > > correctly,
> > > the first failure is on this test:
> > > 
> > > print "Mount $fs_type filesystem on $basedir/mntpoint/mp1\n";
> > > print "Using mount options:\n\t$mount_opts\n";
> > > $result = system(
> > > "runcon -t test_filesystem_no_getattr_t $basedir/mount -s $dev -t
> > > $basedir/mntpoint/mp1 -f $fs_type -o $mount_opts $v"
> > > );
> > > ok( $result eq 0 );
> > > 
> > > Looks like the denial was:
> > > type=SYSCALL msg=audit(03/13/2020 13:11:37.805:1605) :
> > > arch=x86_64
> > > syscall=mount success=no exit=EACCES(Permission denied)
> > > a0=0x7ffc28975328 a1=0x7ffc2897536b a2=0x7ffc28975386 a3=0x0
> > > items=14
> > > ppid=15745 pid=15886 auid=sds uid=root gid=root euid=root
> > > suid=root
> > > fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1
> > > comm=mount
> > > exe=/mnt/selinux-testsuite/tests/filesystem/mount
> > > subj=unconfined_u:unconfined_r:test_filesystem_no_getattr_t:s0-
> > > s0:c0.c1023
> > > key=(null)
> > > type=AVC msg=audit(03/13/2020 13:11:37.805:1605) :
> > > avc:  denied  {
> > > search } for  pid=15886 comm=mount name=sds dev="0:49"
> > > ino=17039361
> > > scontext=unconfined_u:unconfined_r:test_filesystem_no_getattr_t:s
> > > 0-
> > > s0:c0.c1023
> > > tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
> > > permissive=0
> > 
> > So far I have not managed to see this problem before or after a
> > restorecon. I'll investigate further and see what I can find !!!
> 
> I was wondering if it has to do with where the testsuite directory is
> located.
> In my case, under my $HOME. Most of the test domains don't need
> access to
> the parent directories of the test subdir because they only use
> relative pathnames
> but a few do require this.

Yes I use a mixture of relative and absolute paths (mainly because
MS_BIND / MS_PRIVATE require abs paths). I'll test as you do and I
guess update the policy.