Bug 495614 - with !allow_execmem, mmap(PROT_WRITE|PROT_READ|PROT_EXEC) not failing
with !allow_execmem, mmap(PROT_WRITE|PROT_READ|PROT_EXEC) not failing
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-13 23:19 EDT by Adam Goode
Modified: 2009-04-15 10:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-14 09:59:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case for execmem (210 bytes, text/plain)
2009-04-13 23:19 EDT, Adam Goode
no flags Details

  None (edit)
Description Adam Goode 2009-04-13 23:19:56 EDT
Created attachment 339413 [details]
test case for execmem

Description of problem:
selinux is supposed to block mmap of writable and executable pages. This does not seem to be working.


Version-Release number of selected component (if applicable):
kernel-2.6.27.19-170.2.35.fc10.i686
selinux-policy-targeted-3.5.13-54.fc10.noarch

How reproducible:
Always?


Steps to Reproduce:
1. Compile execmem.c (attached)
2. setenforce 1
3. semanage boolean -m --off allow_execmem
4. ./execmem
  
Actual results:
mmap succeeds


Expected results:
mmap fails
Comment 1 Daniel Walsh 2009-04-14 09:59:10 EDT
Turn off allow_execstack

# semanage boolean -m --off allow_execstack

./execmem 
z: 0xffffffffffffffff
----
time->Tue Apr 14 09:57:38 2009
type=SYSCALL msg=audit(1239717458.848:73): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=7580 pid=1183 auid=3267 uid=3267 gid=3267 euid=3267 suid=3267 fsuid=3267 egid=3267 sgid=3267 fsgid=3267 tty=pts3 ses=1 comm="execmem" exe="/home/dwalsh/Download/execmem" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1239717458.848:73): avc:  denied  { execmem } for  pid=1183 comm="execmem" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process


allow_execstack allows both execmem and execstack.
Comment 2 Adam Goode 2009-04-14 11:23:04 EDT
Ok, the weird thing is that sometimes it was failing. Are there conditions where execstack doesn't always imply execmem? Maybe how randomization is done?

Also, is there a bug for execstack implies execmem?
Comment 3 Daniel Walsh 2009-04-14 11:39:27 EDT
I am sure there are situations where execstack does not imply execmem, and maybe we should break these apart.  I think the problem was that as soon as someone hit an execstack violation, invariably they would next hit the execmem, so we combined them.
Comment 4 Adam Goode 2009-04-14 13:34:43 EDT
Shouldn't execmem not be allowed if the application's executable stack flag is cleared? Otherwise, execmem is just allowed in all cases, correct? The number of applications that actually need execstack are small and flagged as such, yes?
Comment 5 Daniel Walsh 2009-04-14 14:05:02 EDT
Ok, I removed the execmem from allow_execstack for F11.  We will see how it goes.
Comment 6 Adam Goode 2009-04-14 15:05:47 EDT
Won't that break things as in bug #211271 ?

I was saying only allow execmem/execstack if the executable stack flag is set. Does selinux know how to read that flag?
Comment 7 Daniel Walsh 2009-04-15 10:12:04 EDT
Great catch.  I will turn it back. There is no "selinux"  just the kernel.  And I guess it does not.
Comment 8 Adam Goode 2009-04-15 10:58:06 EDT
I think the kernel does know how to read the flag. Look for PT_GNU_STACK in fs/binfmt_elf.c. This flag is used to set the initial page permissions. Maybe it should also be used to set execstack/execmem. There is no reason to allow execstack (and therefore unnecessary execmem) if the flag says we don't want it, right?

Note You need to log in before you can comment on or make changes to this bug.