On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > selinux-testsuite exercises the individual kernel permission checks using > its own privately defined test domains and types, so a failure indicates a > kernel bug or a bug in the test policy or test code, not a bug in the > distribution policy package. It could be that a change in the distribution > policy has a side effect (e.g. allowing some permission to all domains that > we are trying to test such that we cannot trigger a failure, as in this > case), but the testsuite tries to work around such cases by setting any > necessary global booleans for the test duration and/or custom defining the > test domain in such a way that it does not inherit anything from the > distribution policy. > > The exec* checks can be disabled on certain architectures if they default to > executable data but that would affect more than just execmod (and s390 does > not default to executable data). > > Can you check that execmod permission is NOT granted to test_no_execmod_t: > $ sesearch -AC -s test_no_execmod_t -p execmod > > Can you confirm that the test program is not marked with executable stack > flag: > $ execstack -q tests/mmap/mprotect_file_private_execmod > > Otherwise, I think you need some kernel instrumentation / tracing to see > what is happening, particularly the selinux_file_mprotect() function. I have been working with Jan on this and it appears that the issue is due to the READ_IMPLIES_EXEC personality being set on the affected s390x kernels. -- paul moore www.paul-moore.com _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
