Bug 178973 - firefox need execmem
firefox need execmem
Status: CLOSED DUPLICATE of bug 180726
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Wan-Teh Chang
: Security
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-01-25 16:10 EST by Daniel Walsh
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-20 14:10:00 EST
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 Daniel Walsh 2006-01-25 16:10:56 EST
Description of problem:

time->Tue Jan 24 22:59:56 2006
type=SYSCALL msg=audit(1138161596.738:7639): arch=40000003 syscall=125
success=yes exit=0 a0=9655b000 a1=a00000 a2=7 a3=96f5abe0 items=0 pid=3198
auid=4294967295 uid=3267 gid=3267 euid=3267 suid=3267 fsuid=3267 egid=3267
sgid=3267 fsgid=3267 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin"
type=AVC msg=audit(1138161596.738:7639): avc:  granted  { execmem } for 
pid=3198 comm="firefox-bin" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c4
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c4 tclass=process


http://people.redhat.com/drepper/selinux-mem.html
Comment 1 Matthias Clasen 2006-02-15 16:23:39 EST
Caillon, whats the status of this ? 
Comment 2 Christopher Aillon 2006-02-15 17:18:47 EST
Issue in NSPR based on my reading of Uli's link.  I think this is different from
bug 180726, but not sure.

/nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/pr/src/md/unix/nextstep.c, line 146 -- case PROT_EXEC: mach_prot =
VM_PROT_EXECUTE; break;
/nsprpub/pr/src/md/unix/unix.c, line 2945 -- prot |= PROT_EXEC;
Comment 3 Ulrich Drepper 2006-02-15 17:32:42 EST
The /nsprpub/pr/src/md/unix/unix.c case is:

    /*
     * On Alpha Linux, the user-level thread stack needs
     * to be made executable because longjmp/signal seem
     * to put machine instructions on the stack.
     */
#if defined(LINUX) && defined(__alpha)
    prot |= PROT_EXEC;
#endif

No problem for us.  If somebody cares about Alpha they could look at it.

/nsprpub/pr/src/md/unix/nextstep.c is also irrelevant, who cares aobut NextStep?

The first case in /nsprpub/lib/msgc/src/unixgc.c is a real issue.  It simply
shouldn't be necessary to have execution permission.  If somebody needs it this
should be explicitly requested.  The second case is commented out.
Comment 4 Kai Engert (:kaie) 2006-02-20 07:08:54 EST
Wan-Teh, it seems heap memory allocation in NSPR requests executable memory,
which is undesirable by selinux.
Comment 5 David Baron 2006-02-20 13:16:08 EST
(In reply to comment #2)
> /nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
> PROT_READ|PROT_WRITE|PROT_EXEC,
> /nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
> allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,

It doesn't look like anything actually builds this file; there are no references
to the msgc directory from outside of it.
Comment 6 Wan-Teh Chang 2006-02-20 13:44:23 EST
The four uses of PROT_EXEC that caillon listed in
comment 2 are all in dead code.

Dan, the Hardware field of this bug report is set to All.
what hardware have you reproduced this bug on?  If you
only saw this bug with a 64-bit Firefox build for x86_64,
this bug could be a duplicate of bug 180726.  Can you
still reproduce this bug?
Comment 7 Daniel Walsh 2006-02-20 13:57:19 EST
I have not been able to reproduce, so the bug very well could be coming from X86_64.
Comment 8 Wan-Teh Chang 2006-02-20 14:10:00 EST
With the information we have, and the fact that this
bug has been fixed, I'm marking this bug a duplicate of
bug 180726.

*** This bug has been marked as a duplicate of 180726 ***
Comment 9 Christopher Aillon 2006-02-20 14:16:54 EST
execstack and execmem are two different things.  I don't think they are the same
bug.
Comment 10 Wan-Teh Chang 2006-02-20 14:40:36 EST
Good point, caillon.  Should we resolve this bug WORKSFORME
then?

Just to make sure I've done my due diligence, I searched for
PROT_EXEC in the Firefox 1.5 source tree:

http://lxr.mozilla.org/mozilla1.8.0/search?string=PROT_EXEC

I got the following hits:

/calendar/libical/src/libical/vsnprintf.c, line 99 --
PROT_READ|PROT_WRITE|PROT_EXEC) == -1)
/gc/boehm/os_dep.c, line 139 -- # define OPT_PROT_EXEC PROT_EXEC
/gc/boehm/os_dep.c, line 141 -- # define OPT_PROT_EXEC 0
/gc/boehm/os_dep.c, line 1067 -- result = mmap(last_addr, bytes, PROT_READ |
PROT_WRITE | OPT_PROT_EXEC,
/gc/boehm/os_dep.c, line 1410 -- PROT_READ | OPT_PROT_EXEC) < 0) { \
/gc/boehm/os_dep.c, line 1415 -- PROT_WRITE | PROT_READ | OPT_PROT_EXEC ) < 0) { \
/nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/pr/src/md/unix/nextstep.c, line 146 -- case PROT_EXEC: mach_prot =
VM_PROT_EXECUTE; break;
/nsprpub/pr/src/md/unix/unix.c, line 2945 -- prot |= PROT_EXEC;

I believe the first file is not used by Firefox.
The second file (five hits) seems to be an optional,
memory-leak debugging feature.
The last four hits in NSPR are what caillon reported
in comment 2; they are all in dead code (not compiled).
Comment 11 Kai Engert (:kaie) 2006-02-20 14:58:50 EST
> execstack and execmem are two different things.  
> I don't think they are the same bug.

I just made a final test.
On my rawhide x86_64 system, I reinstalled the older NSS package that does not
have the fix.

Then I ran firefox.

We know that we had an "execstack" problem. However, the log messages I get
mention "execmem". I think that's another indication that what has been reported
here is the same bug.
Comment 12 Christopher Aillon 2006-02-20 15:16:55 EST
Could very well be then.
Comment 13 Wan-Teh Chang 2006-02-20 17:06:29 EST
Kai, thank you for verifying that the executable stack
in NSS caused an "execmem" log message.

*** This bug has been marked as a duplicate of 180726 ***

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