Bug 175275 - All Firefox/Thunderbird libraries require execmod privs
All Firefox/Thunderbird libraries require execmod privs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: Security
: 164308 (view as bug list)
Depends On: 175442
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-08 09:43 EST by Daniel Walsh
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version: current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-15 23:36:45 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)
program causing execmod error (312 bytes, text/plain)
2005-12-08 11:48 EST, Ulrich Drepper
no flags Details

  None (edit)
Description Daniel Walsh 2005-12-08 09:43:56 EST
Description of problem:
Trying to turn off allow_execmod privs for unconfined users in selinux reveals 
every library in firefox/thunderbird requires execmod privs.

I think this is a build problem.  But it makes lessens the impact of SELinux
security, if we have to allow firefox/thunderbird execmod.
Comment 1 Ulrich Drepper 2005-12-08 11:34:29 EST
Further info from Dan (this is x86):

type=AVC msg=audit(1134059072.439:347): avc: denied { execmod } for pid=13023
comm="thunderbird-bin" name="libxpcom_core.so" dev=dm-0 ino=2675268
scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file

With ausearch:

type=SYSCALL msg=audit(1134059072.547:348): arch=40000003 syscall=125 success=no
exit=-13 a0=e2f000 a1=df000 a2=5 a3=bfb376c0 items=0 pid=13033 auid=4294967295
uid=3267 gid=3267 euid=3267 suid=3267 fsuid=3267 egid=3267 sgid=3267
fsgid=3267comm="thunderbird- bin" exe="/usr/lib/thunderbird-1.5/thunderbird-bin"

This means in libxpcom_core.so there is a mprotect() call which tries to add
execution permission (PROT_EXEC) to a writable (written-to), non-shared memory
region.  This is a huge security problem since it means that intruding code can
add code there and then execute it.

I'll add some more info later.
Comment 2 Ulrich Drepper 2005-12-08 11:48:29 EST
Created attachment 122035 [details]
program causing execmod error

This is a little program to demonstrate what an execmod error is.  The file is
mapped read/write, written too (it's a private mapping, no MAP_SHARED used),
and then made executable.  This is very dangerous.

Take a look at the xpcom sources to find such mprotect calls.
Comment 3 Christopher Aillon 2005-12-08 13:38:40 EST
Any insight on what solutions are available?
Comment 4 Ulrich Drepper 2005-12-08 15:37:47 EST
See

http://people.redhat.com/drepper/selinux-mem.html

for a bit more information.
Comment 5 Ulrich Drepper 2005-12-09 02:50:51 EST
OK, the problem is not the mozilla code per se.  The reason for the error is
that there are test relocations.

Now, there should not be any text relocations in the DSOs.  This should be fixed.  

Until then, it is important to mark all the DSOs with text relocations with
system_u:object_r:texrel_shlib_t.
Comment 6 Ulrich Drepper 2005-12-10 16:32:03 EST
The real requirement is bug 175442.  I don't like the idea _at all_ that
texrel_shlib_t labels are added for all the DSOs.
Comment 7 Bojan Smojver 2005-12-18 13:59:16 EST
Just a me too:

---------------------------------------
type=AVC msg=audit(1134931991.238:67): avc:  denied  { execmod } for  pid=2886 c
omm="firefox-bin" name="libmozjs.so" dev=hda2 ino=328157 scontext=user_u:system_
r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=SYSCALL msg=audit(1134931991.238:67): arch=40000003 syscall=125 success=yes
 exit=0 a0=773000 a1=97000 a2=5 a3=bff7bad0 items=0 pid=2886 auid=4294967295 uid
=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="firef
ox-bin" exe="/usr/lib/firefox-1.5/firefox-bin"
type=AVC_PATH msg=audit(1134931991.238:67):  path="/usr/lib/firefox-1.5/libmozjs.so"
---------------------------------------
Comment 8 Bojan Smojver 2005-12-18 14:08:02 EST
BTW, just confirming that the relabelling from comment #6 works around the
problem here.
Comment 9 Daniel Walsh 2006-01-02 12:15:03 EST
Added policy rules until gcc is fixed.

selinux-policy-2.1.6-19
Comment 10 Ray Strode [halfline] 2006-01-11 11:21:43 EST
*** Bug 164308 has been marked as a duplicate of this bug. ***
Comment 11 Christopher Aillon 2006-01-26 22:53:44 EST
I don't think there's anything for firefox/thunderbird to do other than rebuild
once gcc is fixed.  Taking off the FC5Blocker list as there's a workaround in
selinux-policy
Comment 12 Daniel Walsh 2007-03-15 23:36:45 EDT
Closing several old modified bugs
Comment 13 Dawid Gajownik 2007-03-16 12:48:44 EDT
Maybe selinux-policy should be now updated (textrel_shlib_t → lib_t)?

[y4kk0@X ~]$ eu-findtextrel /usr/lib/firefox-1.5.0.10/libmozjs.so
eu-findtextrel: no text relocations reported in
'/usr/lib/firefox-1.5.0.10/libmozjs.so'
[y4kk0@X ~]$ ls -Z /usr/lib/firefox-1.5.0.10/libmozjs.so
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t
/usr/lib/firefox-1.5.0.10/libmozjs.so
[y4kk0@X ~]$


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