SELinux Archive on lore.kernel.org
 help / color / Atom feed
* Possible regression test failure?
@ 2019-05-04  3:42 Dan Noland
  2019-05-04 18:00 ` Ondrej Mosnacek
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Noland @ 2019-05-04  3:42 UTC (permalink / raw)
  To: selinux

- Hello -

I am running a CentOS (7.6.1810 Core) base system with a 4.19.0-x
kernel. I have a fresh clone of the selinux-testsuite from
github. Before invoking "make -C policy load" I am running only the
targeted policy in the enforcing mode. I am consistently seeing a
single failure in the mmap regression tests: 

not ok 27
# Failed test 27 in ./mmap/test at line 143
#  ./mmap/test line 143 is:     ok($result);

Other than this one failure things seem to be OK according to the test 
summary:

Test Summary Report
-------------------
mmap/test                 (Wstat: 0 Tests: 47 Failed: 1)
  Failed test:  27
  Files=51, Tests=520, 35 wallclock secs ( 0.11 usr  0.03 sys +  0.82
  cusr  0.85 \
  csys =  1.81 CPU)
  Result: FAIL
  Failed 1/51 test programs. 1/520 subtests failed.

The test in question is:

/bin/runcon -t test_no_map_t -- $basedir/mmap_file_shared $basedir/temp_file

Investigation indicates that the failure is caused by a bad (EACCES) open()
at mmap_file_shared.c:38   

The AVC in the audit log shows that the { search } permission was
missing.

type=AVC msg=audit(1556938308.571:936): avc:  denied  { search } for
pid=7517 comm="mmap_file_share" name="vagrant" dev="dm-0" ino=81922
scontext=unconfined_u:unconfined_r:test_no_map_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
permissive=0
type=SYSCALL msg=audit(1556938308.571:936): arch=c000003e syscall=2
success=no exit=-13 a0=7ffcc17da74a a1=2 a2=8 a3=7ffcc17d8d20 items=0
ppid=7512 pid=7517 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts1 ses=4 comm="mmap_file_share"
exe="/home/vagrant/selinux-testsuite/tests/mmap/mmap_file_shared"
subj=unconfined_u:unconfined_r:test_no_map_t:s0-s0:c0.c1023 key=(null)
type=PROCTITLE msg=audit(1556938308.571:936):
proctitle=2F686F6D652F76616772616E742F73656C696E75782D7465737473756974652F74657374732F6D6D61702F6D6D61705F66696C655F736861726564002F686F6D652F76616772616E742F73656C696E75782D7465737473756974652F74657374732F6D6D61702F74656D705F66696C65

My understanding of the intent of this regression test is limited,
but I don't think this is an intended negative result.

Any wisdom on how I should understand and address this failure would
be gratefully received.

-- 
TY,
Dan Noland

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possible regression test failure?
  2019-05-04  3:42 Possible regression test failure? Dan Noland
@ 2019-05-04 18:00 ` Ondrej Mosnacek
  2019-05-06 17:14   ` Dan Noland
  0 siblings, 1 reply; 3+ messages in thread
From: Ondrej Mosnacek @ 2019-05-04 18:00 UTC (permalink / raw)
  To: Dan Noland; +Cc: selinux

Hi Dan,

On Sat, May 4, 2019 at 5:42 AM Dan Noland <dan@starlab.io> wrote:
> - Hello -
>
> I am running a CentOS (7.6.1810 Core) base system with a 4.19.0-x
> kernel. I have a fresh clone of the selinux-testsuite from
> github. Before invoking "make -C policy load" I am running only the
> targeted policy in the enforcing mode. I am consistently seeing a
> single failure in the mmap regression tests:
>
> not ok 27
> # Failed test 27 in ./mmap/test at line 143
> #  ./mmap/test line 143 is:     ok($result);
>
> Other than this one failure things seem to be OK according to the test
> summary:
>
> Test Summary Report
> -------------------
> mmap/test                 (Wstat: 0 Tests: 47 Failed: 1)
>   Failed test:  27
>   Files=51, Tests=520, 35 wallclock secs ( 0.11 usr  0.03 sys +  0.82
>   cusr  0.85 \
>   csys =  1.81 CPU)
>   Result: FAIL
>   Failed 1/51 test programs. 1/520 subtests failed.
>
> The test in question is:
>
> /bin/runcon -t test_no_map_t -- $basedir/mmap_file_shared $basedir/temp_file
>
> Investigation indicates that the failure is caused by a bad (EACCES) open()
> at mmap_file_shared.c:38
>
> The AVC in the audit log shows that the { search } permission was
> missing.
>
> type=AVC msg=audit(1556938308.571:936): avc:  denied  { search } for
> pid=7517 comm="mmap_file_share" name="vagrant" dev="dm-0" ino=81922
> scontext=unconfined_u:unconfined_r:test_no_map_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
> permissive=0
> type=SYSCALL msg=audit(1556938308.571:936): arch=c000003e syscall=2
> success=no exit=-13 a0=7ffcc17da74a a1=2 a2=8 a3=7ffcc17d8d20 items=0
> ppid=7512 pid=7517 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts1 ses=4 comm="mmap_file_share"
> exe="/home/vagrant/selinux-testsuite/tests/mmap/mmap_file_shared"
> subj=unconfined_u:unconfined_r:test_no_map_t:s0-s0:c0.c1023 key=(null)
> type=PROCTITLE msg=audit(1556938308.571:936):
> proctitle=2F686F6D652F76616772616E742F73656C696E75782D7465737473756974652F74657374732F6D6D61702F6D6D61705F66696C655F736861726564002F686F6D652F76616772616E742F73656C696E75782D7465737473756974652F74657374732F6D6D61702F74656D705F66696C65
>
> My understanding of the intent of this regression test is limited,
> but I don't think this is an intended negative result.
>
> Any wisdom on how I should understand and address this failure would
> be gratefully received.

RHEL (and likely also CentOS) 7.6 has the domain_can_mmap_files
SELinux boolean set to "on" by default [1], which basically means that
map permissions are not checked, which logically leads to the failure
of the test that checks that map permission is denied when it was not
allowed by the test policy. When running the testsuite on CentOS/RHEL
7.6, you need to turn off the domain_can_mmap_files boolean during
test execution:

# setsebool domain_can_mmap_files off
(run the testsuite)
# setsebool domain_can_mmap_files on

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.6_release_notes/index#BZ1460322

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possible regression test failure?
  2019-05-04 18:00 ` Ondrej Mosnacek
@ 2019-05-06 17:14   ` Dan Noland
  0 siblings, 0 replies; 3+ messages in thread
From: Dan Noland @ 2019-05-06 17:14 UTC (permalink / raw)
  To: Ondrej Mosnacek; +Cc: selinux

The 05/04/2019 20:00, Ondrej Mosnacek wrote:
> Hi Dan,
> 
> On Sat, May 4, 2019 at 5:42 AM Dan Noland <dan@starlab.io> wrote:
> > - Hello -
> >
> > I am running a CentOS (7.6.1810 Core) base system with a 4.19.0-x
> > kernel. I have a fresh clone of the selinux-testsuite from
> > github. Before invoking "make -C policy load" I am running only the
> > targeted policy in the enforcing mode. I am consistently seeing a
> > single failure in the mmap regression tests:
> >
> > not ok 27
> > # Failed test 27 in ./mmap/test at line 143
> > #  ./mmap/test line 143 is:     ok($result);
> >

> >
> > Any wisdom on how I should understand and address this failure would
> > be gratefully received.
> 
> RHEL (and likely also CentOS) 7.6 has the domain_can_mmap_files
> SELinux boolean set to "on" by default [1], which basically means that
> map permissions are not checked, which logically leads to the failure
> of the test that checks that map permission is denied when it was not
> allowed by the test policy. When running the testsuite on CentOS/RHEL
> 7.6, you need to turn off the domain_can_mmap_files boolean during
> test execution:
> 
> # setsebool domain_can_mmap_files off
> (run the testsuite)
> # setsebool domain_can_mmap_files on
> 
> [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.6_release_notes/index#BZ1460322
> 

- Ondrej -

That was exactly the problem. Thank you.

-- 
TY,
Dan Noland

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-04  3:42 Possible regression test failure? Dan Noland
2019-05-04 18:00 ` Ondrej Mosnacek
2019-05-06 17:14   ` Dan Noland

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org selinux@archiver.kernel.org
	public-inbox-index selinux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox