| Message ID | 20200312113637.20355-1-richard_c_haines@btinternet.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | selinux-testsuite: Use native filesystem for tests | expand |
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 # Failed test at filesystem/test line 679. Failed umount(2): Invalid argument # Failed test at filesystem/test line 690. Failed mount(2): Permission denied filesystem/test ............. 21/27 # Failed test at filesystem/test line 714. Failed umount(2): Invalid argument # Failed test at filesystem/test line 726. Failed mount(2): Permission denied # Failed test at filesystem/test line 750. filesystem/test ............. 25/27 # Failed test at filesystem/test line 756. Failed umount(2): Invalid argument # Failed test at filesystem/test line 763. # Looks like you failed 7 tests of 27. filesystem/test ............. Dubious, test returned 7 (wstat 1792, 0x700) Failed 7/27 subtests fs_filesystem/test .......... 18/26 Failed fsconfig(2): Permission denied Failed config_opts # Failed test at fs_filesystem/test line 706. fs_filesystem/test .......... 20/26 Failed umount(2): Invalid argument # Failed test at fs_filesystem/test line 717. Failed fsconfig(2): Permission denied Failed config_opts fs_filesystem/test .......... 23/26 # Failed test at fs_filesystem/test line 780. # Failed test at fs_filesystem/test line 786. Failed umount(2): Invalid argument # Failed test at fs_filesystem/test line 794. fs_filesystem/test .......... 26/26 # Looks like you failed 5 tests of 26. fs_filesystem/test .......... Dubious, test returned 5 (wstat 1280, 0x500) Failed 5/26 subtests Test Summary Report ------------------- filesystem/test (Wstat: 1792 Tests: 27 Failed: 7) Failed tests: 18, 20-21, 23-26 Non-zero exit status: 7 fs_filesystem/test (Wstat: 1280 Tests: 26 Failed: 5) Failed tests: 19, 21, 23-25 Non-zero exit status: 5 Files=63, Tests=623, 164 wallclock secs ( 0.36 usr 0.99 sys + 2.77 cusr 48.23 csys = 52.35 CPU) Result: FAIL Failed 2/63 test programs. 12/623 subtests failed. make: *** [Makefile:133: test] Error 5 make: Leaving directory '/mnt/selinux-testsuite/tests' Test failed on line: 72 - Closing down NFS
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...
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:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir permissive=0
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: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 !!!
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: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 !!! 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.
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.
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. Could you try adding "userdom_search_user_home_content(filesystemdomain)" to test_filesystem.te as I had that in RFC V3 patch but removed it when I ran restorecon my system.
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/ Changes from RFC V3: 1) Fixed question mark (?) as the total/planned number of tests (Fix: do not have print statements in BEGIN { }, or any subroutines that are called inside this). 2) nfs.sh now gives line number on all test fails. 3) Policy changes for NFS mnt_t and mounton 4) Added xfslibs-dev and uuid-dev for travis To test fanotify fs watch perms on 5.4+ (will also include tests/notify): 1) Extract the base module (base.cil): semodule -c -E base 2) Backup, the edit the following definitions in base.cil to add watch permissions: (common file (ioctl read write ....)) Add: watch watch_mount watch_sb watch_with_perm watch_reads (class filesystem (mount remount ....)) Add: watch 3) Insert modified base module (inserts with default priority 400): semodule -i base.cil 4) Backup, then edit the following definitions in: /usr/share/selinux/devel/include/support/all_perms.spt define(`all_file_perms',`{ ioctl read write .... Add: watch watch_mount watch_sb watch_with_perm watch_reads define(`all_dir_perms',`{ ioctl read write .... Add: watch watch_mount watch_sb watch_with_perm watch_reads define(`all_filesystem_perms',`{ mount remount .... Add: watch 5) 'make test' can now be run. NOTE: Do NOT leave the new base.cil active after tests, as the system may not reboot if in enforcing mode, as various watch permissions will be denied. Revert to the original (priority 100) as follows: semodule -r base make clean make -C policy unload Finally restore the original: /usr/share/selinux/devel/include/support/all_perms.spt Richard Haines (2): selinux-testsuite: Use native filesystem for tests - Part 1 selinux-testsuite: Use native filesystem for tests - Part 2 .travis.yml | 2 + README.md | 15 +- defconfig | 6 + policy/test_filesystem.te | 89 +- policy/test_filesystem_name_trans.te | 6 + policy/test_filesystem_notify.te | 41 +- tests/filesystem/.gitignore | 1 + tests/filesystem/Filesystem.pm | 111 ++- tests/filesystem/Makefile | 3 +- tests/filesystem/test | 1199 +++++++++++++++--------- tests/filesystem/xfs_quotas_test.c | 96 ++ tests/fs_filesystem/Makefile | 3 - tests/fs_filesystem/fsmount.c | 5 +- tests/fs_filesystem/test | 1300 ++++++++++++++++---------- tests/nfs_filesystem/test | 358 +++++++ tests/nfsruntests.pl | 5 + tools/nfs.sh | 125 ++- 17 files changed, 2362 insertions(+), 1003 deletions(-) create mode 100644 tests/filesystem/xfs_quotas_test.c create mode 100755 tests/nfs_filesystem/test create mode 100755 tests/nfsruntests.pl