Bug 495614 - with !allow_execmem, mmap(PROT_WRITE|PROT_READ|PROT_EXEC) not failing
Summary: with !allow_execmem, mmap(PROT_WRITE|PROT_READ|PROT_EXEC) not failing
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 10
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-14 03:19 UTC by Adam Goode
Modified: 2009-04-15 14:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-14 13:59:10 UTC
Type: ---
Embargoed:


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

Description Adam Goode 2009-04-14 03:19:56 UTC
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 13:59:10 UTC
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 15:23:04 UTC
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 15:39:27 UTC
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 17:34:43 UTC
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 18:05:02 UTC
Ok, I removed the execmem from allow_execstack for F11.  We will see how it goes.

Comment 6 Adam Goode 2009-04-14 19:05:47 UTC
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 14:12:04 UTC
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 14:58:06 UTC
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.