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?
_______________________________________________
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.
