subject:"selinux\-testsuite\: mmap execmod test failure on RHEL6.7 s390x"

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

2015-11-05 Thread Stephen Smalley


On 11/05/2015 08:27 AM, Jan Stancek wrote:





- Original Message -

From: "Paul Moore" <p...@paul-moore.com>
To: "Stephen Smalley" <s...@tycho.nsa.gov>
Cc: "Jan Stancek" <jstan...@redhat.com>, selinux@tycho.nsa.gov
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 <s...@tycho.nsa.gov> wrote:

On 11/04/2015 03:32 PM, Paul Moore wrote:


On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley <s...@tycho.nsa.gov> 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 
  #include 
  #include 
+#include 

  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 
guess mprotect_file_private_rx and mprotect_file_private_rwx aren't 
affected because we always apply the file execute check even if the 
mapping is already executable, and likewise for mprotect_anon_* and 
execmem.  Only the checks directly in selinux_file_mprotect() are gated 
by a !(vma->vm_flags & VM_EXEC) test; the ones in file_map_prot_check() 
that are shared with the mmap hook are unconditional.


What does /proc/self/maps look like?

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

2015-11-05 Thread Stephen Smalley


On 11/05/2015 10:45 AM, Jan Stancek wrote:





- Original Message -

From: "Stephen Smalley" <s...@tycho.nsa.gov>
To: "Jan Stancek" <jstan...@redhat.com>, "Paul Moore" <p...@paul-moore.com>
Cc: selinux@tycho.nsa.gov
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" <p...@paul-moore.com>
To: "Stephen Smalley" <s...@tycho.nsa.gov>
Cc: "Jan Stancek" <jstan...@redhat.com>, selinux@tycho.nsa.gov
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 <s...@tycho.nsa.gov> wrote:

On 11/04/2015 03:32 PM, Paul Moore wrote:


On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley <s...@tycho.nsa.gov>
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 
   #include 
   #include 
+#include 

   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=0xfff3

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}, 0x3aafed0) = 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/47

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

2015-11-05 Thread Jan Stancek



- Original Message -
> From: "Stephen Smalley" <s...@tycho.nsa.gov>
> To: "Jan Stancek" <jstan...@redhat.com>, "Paul Moore" <p...@paul-moore.com>
> Cc: selinux@tycho.nsa.gov
> 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" <s...@tycho.nsa.gov>
> >> To: "Jan Stancek" <jstan...@redhat.com>, "Paul Moore"
> >> <p...@paul-moore.com>
> >> Cc: selinux@tycho.nsa.gov
> >> 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" <p...@paul-moore.com>
> >>>> To: "Stephen Smalley" <s...@tycho.nsa.gov>
> >>>> Cc: "Jan Stancek" <jstan...@redhat.com>, selinux@tycho.nsa.gov
> >>>> 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 <s...@tycho.nsa.gov>
> >>>> wrote:
> >>>>> On 11/04/2015 03:32 PM, Paul Moore wrote:
> >>>>>>
> >>>>>> On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley <s...@tycho.nsa.gov>
> >>>>>> 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.
> >>>>>
> >>>>>
> >>&g

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

2015-11-05 Thread Jan Stancek





- Original Message -
> From: "Paul Moore" <p...@paul-moore.com>
> To: "Stephen Smalley" <s...@tycho.nsa.gov>
> Cc: "Jan Stancek" <jstan...@redhat.com>, selinux@tycho.nsa.gov
> 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 <s...@tycho.nsa.gov> wrote:
> > On 11/04/2015 03:32 PM, Paul Moore wrote:
> >>
> >> On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley <s...@tycho.nsa.gov> 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 
 #include 
 #include 
+#include 
 
 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)

Regards,
Jan

> 
> --
> paul moore
> www.paul-moore.com
> 
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

2015-11-04 Thread Paul Moore

On Wed, Nov 4, 2015 at 3:49 PM, Stephen Smalley  wrote:
> On 11/04/2015 03:32 PM, Paul Moore wrote:
>>
>> On Wed, Nov 4, 2015 at 2:21 PM, Stephen Smalley  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.

-- 
paul moore
www.paul-moore.com
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

Re: selinux-testsuite: mmap execmod test failure on RHEL6.7 s390x

5 matches

Site Navigation

Mail list logo

Footer information