Bug 146578 - httpd execmem denial
httpd execmem denial
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-29 17:48 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-11 14:47:14 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)

  None (edit)
Description Ivan Gyurdiev 2005-01-29 17:48:44 EST
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 15:56:33 EST
Any idea what it was trying to do?

Dan
Comment 2 Ivan Gyurdiev 2005-02-01 13:51:51 EST
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 12:09:59 EST
Can no longer reproduce.
Comment 4 Ivan Gyurdiev 2005-05-10 12:35:32 EDT
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 10:13:15 EDT
execstack -q /usr/lib/libbeecrypt.so.6
Comment 6 Ivan Gyurdiev 2005-05-11 13:02:22 EDT
- /usr/lib/libbeecrypt.so.6
Comment 7 Stephen Smalley 2005-05-11 13:31:43 EDT
uname -a
Comment 8 Ivan Gyurdiev 2005-05-11 13:36:37 EDT
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 13:58:19 EDT
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 14:24:36 EDT
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 14:32:08 EDT
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 14:37:59 EDT
[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 14:42:53 EDT
... no execstack with the one from Fedora.
Close the bug?

Sorry about that...
Comment 14 Ivan Gyurdiev 2005-05-11 14:47:14 EDT
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.