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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:
> > On Fri, Mar 13, 2020 at 11:47 AM Stephen Smalley
> > <stephen.smalley.work@xxxxxxxxx> wrote:
> > > On Thu, Mar 12, 2020 at 7:37 AM Richard Haines
> > > <richard_c_haines@xxxxxxxxxxxxxx> 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@xxxxxxxxxx/
> > > 
> > > 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:s0-
> 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 !!!





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux