----- Original Message -----
> From: "Stephen Smalley" <sds@xxxxxxxxxxxxx>
> To: "Jan Stancek" <jstancek@xxxxxxxxxx>, "Paul Moore" <paul@xxxxxxxxxxxxxx>
> Cc: selinux@xxxxxxxxxxxxx
> Sent: Thursday, 5 November, 2015 5:01:28 PM
> Subject: Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x
>
> On 11/05/2015 10:45 AM, Jan Stancek wrote:
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: "Stephen Smalley" <sds@xxxxxxxxxxxxx>
> >> To: "Jan Stancek" <jstancek@xxxxxxxxxx>, "Paul Moore"
> >> <paul@xxxxxxxxxxxxxx>
> >> Cc: selinux@xxxxxxxxxxxxx
> >> Sent: Thursday, 5 November, 2015 3:37:33 PM
> >> Subject: Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x
> >>
> >> On 11/05/2015 08:27 AM, Jan Stancek wrote:
> >>>
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Paul Moore" <paul@xxxxxxxxxxxxxx>
> >>>> To: "Stephen Smalley" <sds@xxxxxxxxxxxxx>
> >>>> Cc: "Jan Stancek" <jstancek@xxxxxxxxxx>, selinux@xxxxxxxxxxxxx
> >>>> Sent: Wednesday, 4 November, 2015 10:51:15 PM
> >>>> Subject: Re: selinux-testsuite: mmap execmod test failure on RHEL6.7
> >>>> s390x
> >>>>
> >>>> On Wed, Nov 4, 2015 at 3:49 PM, Stephen Smalley <sds@xxxxxxxxxxxxx>
> >>>> wrote:
> >>>>> On 11/04/2015 03:32 PM, Paul Moore wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>>
> >>>>> Hmmm...doesn't explain why only execmod failed - that should create
> >>>>> failures
> >>>>> for multiple tests.
> >>>>
> >>>> Yes, it turns out I spoke too soon.
> >>>
> >>> If I add a call to personality(0), the testcase can pass
> >>> (mprotect fails with EACCES):
> >>>
> >>> diff --git a/tests/mmap/mprotect_file_private_execmod.c
> >>> b/tests/mmap/mprotect_file_private_execmod.c
> >>> index ade1981..b2efa05 100644
> >>> --- a/tests/mmap/mprotect_file_private_execmod.c
> >>> +++ b/tests/mmap/mprotect_file_private_execmod.c
> >>> @@ -4,6 +4,7 @@
> >>> #include <errno.h>
> >>> #include <fcntl.h>
> >>> #include <sys/mman.h>
> >>> +#include <sys/personality.h>
> >>>
> >>> int main(int argc, char **argv)
> >>> {
> >>> @@ -11,6 +12,9 @@ int main(int argc, char **argv)
> >>> int rc;
> >>> int fd;
> >>>
> >>> +
> >>> + personality(0);
> >>> +
> >>> if (argc != 2) {
> >>> fprintf(stderr, "usage: %s file\n", argv[0]);
> >>> exit(1);
> >>>
> >>> (strace log)
> >>> ...
> >>> [pid 2976] 08:21:53.928872 personality(PER_LINUX) = 4194304
> >>> [pid 2976] 08:21:53.936870 open("./temp_file", O_RDONLY) = 3
> >>> [pid 2976] 08:21:53.936898 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> >>> MAP_PRIVATE, 3, 0) = 0x3fffd4fa000
> >>> [pid 2976] 08:21:53.936925 mprotect(0x3fffd4fa000, 4096,
> >>> PROT_READ|PROT_EXEC) = -1 EACCES (Permission denied)
> >>>
> >>> (strace log from original)
> >>> ...
> >>> [pid 3165] 08:24:31.480187 open("./temp_file", O_RDONLY) = 3
> >>> [pid 3165] 08:24:31.480294 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> >>> MAP_PRIVATE, 3, 0) = 0x3fffd196000
> >>> [pid 3165] 08:24:31.480318 mprotect(0x3fffd196000, 4096,
> >>> PROT_READ|PROT_EXEC) = 0
> >>>
> >>> # uname -r
> >>> 2.6.32-584.el6.s390x
> >>>
> >>> # cat /etc/redhat-release
> >>> Red Hat Enterprise Linux Server release 6.7 (Santiago)
> >>
> >> Hmm...you have no similar issue with mprotect_stack or mprotect_heap? I
> >
> > No, these work as expected. systemtap trace shows that
> > vma->vm_flags doesn't contain VM_EXEC:
> >
> > mprotect_heap selinux_file_mprotect vma=0x789e7680 reqprot=0x5 prot=0x5,
> > flags: 100073
> > mprotect_heap selinux_file_mprotect return=0xfffffffffffffff3
> >
> > Here is a strace log of "runcon -t test_execmem_t $basedir/mprotect_heap":
> >
> > [pid 4775] 10:31:59.987008 brk(0) = 0xb824a000
> > [pid 4775] 10:31:59.987021 brk(0xb826d000) = 0xb826d000
> > [pid 4775] 10:31:59.987042 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> > [pid 4775] 10:31:59.987060 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0},
> > 8) = 0
> > [pid 4775] 10:31:59.987080 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> > [pid 4775] 10:31:59.987094 nanosleep({30, 0}, 0x3ffffaafed0) = 0
> > ^^ I added this sleep so I can capture /proc/pid/maps
> > [pid 4775] 10:32:29.987868 mprotect(0xb824b000, 4096, PROT_READ|PROT_EXEC)
> > = -1 EACCES (Permission denied)
> >
> > # cat /proc/4775/maps
> > 80000000-80001000 r-xp 00000000 fd:00 787427
> > /root/selinux-testsuite-my/tests/mmap/mprotect_heap
> > 80001000-80002000 rwxp 00000000 fd:00 787427
> > /root/selinux-testsuite-my/tests/mmap/mprotect_heap
> > b824a000-b826d000 rw-p 00000000 00:00 0
> > [heap]
> > 4a9261f000-4a92640000 r-xp 00000000 fd:00 268803
> > /lib64/ld-2.12.so
> > 4a92640000-4a92641000 r-xp 00020000 fd:00 268803
> > /lib64/ld-2.12.so
> > 4a92641000-4a92642000 rwxp 00021000 fd:00 268803
> > /lib64/ld-2.12.so
> > 4a92642000-4a92643000 rw-p 00000000 00:00 0
> > 4a92649000-4a927f9000 r-xp 00000000 fd:00 268804
> > /lib64/libc-2.12.so
> > 4a927f9000-4a927fd000 r-xp 001af000 fd:00 268804
> > /lib64/libc-2.12.so
> > 4a927fd000-4a927fe000 rwxp 001b3000 fd:00 268804
> > /lib64/libc-2.12.so
> > 4a927fe000-4a92803000 rwxp 00000000 00:00 0
> > 3fffd6b4000-3fffd6b6000 rwxp 00000000 00:00 0
> > 3fffd6c3000-3fffd6c6000 rwxp 00000000 00:00 0
> > 3fffd6c6000-3fffd6c8000 r-xp 00000000 00:00 0
> > [vdso]
> > 3ffffa9c000-3ffffab1000 rw-p 00000000 00:00 0
> > [stack]
> >
> > # cat /proc/4775/personality
> > 00400000
>
> Ok, I guess we can go with your patch then. Care to send a properly
> formatted one?
Sure. I have 3 more ready, I just want to test all across various
RHEL distros and architectures first.
Regards,
Jan
>
>
>
>
_______________________________________________
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.
