Bug 136950

Summary: mmap2(), old_mmap() adds execute check, fails with SELinux strict/enforcing
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-27 16:19:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace output of 'realplay.bin' with strict/enforcing
none
strace output of 'realplay.bin' with strict/permissive none

Description Tom London 2004-10-23 20:51:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
Running latest Rawhide, strict/enforcing:

Trying to run 'realplayer' produces the following avc:

Oct 23 11:30:38 fedora kernel: audit(1098556238.386:0): avc:  denied 
{ execute } for  pid=13940 path=/etc/ld.so.cache dev=hda2 ino=4475709
scontext=user_u:user_r:user_mozilla_t
tcontext=system_u:object_r:ld_so_cache_t tclass=file

Notice that is is failing on 'execute'.

Strace produces the following (full output file attached below):
execve("./realplay.bin", ["./realplay.bin"], [/* 36 vars */]) = 0
uname({sys="Linux", node="fedora.tomlondon.dyndns.org", ...}) = 0
brk(0)                                  = 0x80d5000
<<<<<SNIP>>>>>>
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=135566, ...}) = 0
old_mmap(NULL, 135566, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES
(Permission denied)
close(3)                                = 0

Running this in permissive mode, strace produces:

open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=135566, ...}) = 0
old_mmap(NULL, 135566, PROT_READ, MAP_PRIVATE, 3, 0) = 0x886000
close(3)                                 = 0

Showing that the call to 'old_mmap()' succeeds,
and no avc is produced.

Later, the program calls 'mmap2()' a couple of times that
fail with EACCESS (with 'execute' avc produced):

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=38674048, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES
(Permission denied)
close(3)                                = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x116000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2528
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x116000, 4096)                  = 0
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=365, ...}) = 0
mmap2(NULL, 365, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission
denied)
close(3)   

Here is the strace for the first of these calls in permissive mode:

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=38674048, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x920000 close(3)
                               = 0

So the calls to mmap2() and old_mmap() sometime seem to 
erroneously add checks for 'execute'.  This causes failures.....






Version-Release number of selected component (if applicable):
kernel-2.6.9-1.640

How reproducible:
Always

Steps to Reproduce:
1. Try to run realplayer in strict/enforcing
2. Fails...
3.
    

Additional info:

Comment 1 Tom London 2004-10-23 20:53:09 UTC
Created attachment 105695 [details]
strace output of 'realplay.bin' with strict/enforcing

Comment 2 Tom London 2004-10-23 20:54:17 UTC
Created attachment 105696 [details]
strace output of 'realplay.bin' with strict/permissive

Comment 3 Tom London 2004-10-27 16:19:46 UTC
Stephen Smalley explained this ...

This is an issue with 'legacy binaries' that lack the PT_GNU_STACK
segment header.

Without it, the kernel adds PROT_EXEC to PROT_READ to support
executing off the stack.

Sorry for the false alarm.