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
Caillon, whats the status of this ?
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;
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.
Wan-Teh, it seems heap memory allocation in NSPR requests executable memory, which is undesirable by selinux.
(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.
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?
I have not been able to reproduce, so the bug very well could be coming from X86_64.
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 ***
execstack and execmem are two different things. I don't think they are the same bug.
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).
> 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.
Could very well be then.
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 ***