Bug 146578 - httpd execmem denial
Summary: httpd execmem denial
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-29 22:48 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-11 18:47:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ivan Gyurdiev 2005-01-29 22:48:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
audit(1107038086.210:0): avc:  denied  { execmem } for  pid=3259
comm=httpd scontext=system_u:system_r:httpd_t
tcontext=system_u:system_r:httpd_t tclass=process


Version-Release number of selected component (if applicable):
selinux-policy-strict-1.21.5-2

How reproducible:
Didn't try

Steps to Reproduce:
  

Additional info:

Comment 1 Daniel Walsh 2005-01-31 20:56:33 UTC
Any idea what it was trying to do?

Dan

Comment 2 Ivan Gyurdiev 2005-02-01 18:51:51 UTC
Not a clue, but it is reproducible - occurs with a slight delay 
right after starting the httpd server. 
Is this helpful in any way, or should I be looking for 
something else?

[root@cobra phantom]# strace -o log /usr/sbin/httpd -X

...

[root@cobra phantom]# cat log|grep PROT_EXEC|grep -v MAP_DENYWRITE
mprotect(0xbff8f000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0

...

[root@cobra phantom]# grep PROT_GROWSDOWN -C 10 log
old_mmap(NULL, 60240, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 27, 0) =
0x891000
old_mmap(0x89f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 27, 0xe000) = 0x89f000
close(27)                               = 0
open("/usr/lib/libbeecrypt.so.6", O_RDONLY) = 27
read(27, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\353\304"..., 512) = 512
fstat64(27, {st_mode=S_IFREG|0755, st_size=116656, ...}) = 0
old_mmap(NULL, 118156, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 27, 0) =
0xae2000
old_mmap(0xafc000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 27, 0x19000) = 0xafc000
mprotect(0xe1a000, 3820, PROT_READ|PROT_WRITE) = 0
mprotect(0xe1a000, 3820, PROT_READ)     = 0
mprotect(0xbff8f000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(27)                               = 0
access("/etc/selinux/", F_OK)           = 0
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 27
fstat64(27, {st_mode=S_IFREG|0644, st_size=440, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7d8d000
read(27, "# This file controls the state o"..., 4096) = 440
close(27)                               = 0
munmap(0xb7d8d000, 4096)                = 0
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 27
fstat64(27, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0


Comment 3 Ivan Gyurdiev 2005-02-10 17:09:59 UTC
Can no longer reproduce.


Comment 4 Ivan Gyurdiev 2005-05-10 16:35:32 UTC
Nope - it's back, and it happens every time I start up the webserver.
Not sure what causes it - I use the server for very simple stuff,
and probably never use the functionality that's broken by the denial.

Comment 5 Stephen Smalley 2005-05-11 14:13:15 UTC
execstack -q /usr/lib/libbeecrypt.so.6


Comment 6 Ivan Gyurdiev 2005-05-11 17:02:22 UTC
- /usr/lib/libbeecrypt.so.6

Comment 7 Stephen Smalley 2005-05-11 17:31:43 UTC
uname -a


Comment 8 Ivan Gyurdiev 2005-05-11 17:36:37 UTC
Linux cobra.ivg2.net 2.6.11-1.1275_FC4 #1 Wed Apr 27 14:20:44 EDT 2005 i686
athlon i386 GNU/Linux

Comment 9 Stephen Smalley 2005-05-11 17:58:19 UTC
Attach full strace log, please.
Any reason you aren't running a newer kernel (or more generally, updated against
latest rawhide)?


Comment 10 Ivan Gyurdiev 2005-05-11 18:24:36 UTC
It's available at http://ivan.ivg2.net/httpd.log - 500 K.
(running on the same webserver, actually...)

This is a new log - not the same as before - it probably looks different.
It does report one case of PROT_WRITE | PROT_EXEC, which is what
interested me. 

Log was generated by running httpd -X from the console as sysadm,
until I got the denial I wanted, and then I killed it.

I don't run a newer kernel, because this one's reasonably recent, 
and it's a pain to change kernels, since I have to reinstall
the Nvidia driver yet again - isn't latest 1276 or something?
I'll update it today. 

Comment 11 Stephen Smalley 2005-05-11 18:32:08 UTC
Actually, I just discovered that the latest rawhide kernels don't boot on my
hardware.  Presently running 1.1286; anything newer causes /sbin/init to die for
me even with selinux=0.

Anyway, from your log, the last opened so file was /usr/lib/libgcrypt.so.11,
which doesn't exist on my system and I don't know where you got it.  execstack
-q and rpm -q -f it, please.






Comment 12 Ivan Gyurdiev 2005-05-11 18:37:59 UTC
[phantom@cobra ~]$ execstack -q /usr/lib/libgcrypt.so.11
X /usr/lib/libgcrypt.so.11

[phantom@cobra ~]$ rpm -qf /usr/lib/libgcrypt.so.11
libgcrypt11-1.2.1-10.rhfc3.at

...doh..

I guess I'll be getting rid of that, to test with the one
from Fedora.

Comment 13 Ivan Gyurdiev 2005-05-11 18:42:53 UTC
... no execstack with the one from Fedora.
Close the bug?

Sorry about that...

Comment 14 Ivan Gyurdiev 2005-05-11 18:47:14 UTC
See, if extras had all the stuff I wanted, 
and was kept up to date, I wouldn't have to use
so many external repositories...

By the way, where's the official "Extras (development)" located now - 
I'm not quite sure I have the right URL.


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