After upgrading to the Firefox 4 of Fedora 15, Firefox crashes immediately on startup. I get an AVC about execmem being denied. I run with allow_execmem disabled. (Audit details below.) I used strace and gdb and found out that this happens in a file called xulrunner-2.0.1/mozilla-2.0/js/src/assembler/jit/ExecutableAllocateorPosix.cpp where it does
void* allocation = mmap(NULL, n, INITIAL_PROTECTION_FLAGS, MAP_PRIVATE | MAP_ANON, VM_TAG_FOR_EXECUTABLEALLOCATOR_MEMORY, 0);
The definition of INITIAL_PROTECTION_FLAGS is PROT_READ|PROT_WRITE|PROT_EXEC which indeed looks like something that would be disallowed without allow_execmem.
To make more mysterious, on a different system where we have an fresh installation of Fedora 15, not updated from earlier versions, firefox DO work. It does so even if I turn off allow_execmem. And when I check /proc/*/maps for the firefox process, there are several anonymous regions with "rwxp" permission.
How can it do that? What is it that allows the firefox on the freshly installed F15 system allocate executable and writeable pages? If I knew, maybe I would know what am I missing on the upgraded system?
================================================================
node=mimmi type=AVC msg=audit(1308408766.500:147502): avc: denied { execmem } for pid=23119 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process node=mimmi type=SYSCALL msg=audit(1308408766.500:147502): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=23116 pid=23119 auid=918 uid=918 gid=918 euid=918 suid=918 fsuid=918 egid=918 sgid=918 fsgid=918 tty=pts1 ses=9147 comm="firefox" exe="/usr/lib64/firefox-4/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
On Sat, 2011-06-18 at 19:34 +0200, Göran Uddeborg wrote:
How can it do that? What is it that allows the firefox on the freshly installed F15 system allocate executable and writeable pages? If I knew, maybe I would know what am I missing on the upgraded system?
its x86_64 vs. 686 issue
x86_64 does not need execmem.
You can change the context of the firefox executable to execmem_exec_t i believe and that should probably make it work
you can also set boolean allow_execmem to true i believe
or you can use audit2allow to allow this access
Dominick Grift:
its x86_64 vs. 686 issue
x86_64 does not need execmem.
But both of these systems are x86_64 systems.
More exactly, why doesn't x86_64 need execmem? Firefox does apparently allocate memory that is both executable and writeable on x86_64 systems too.
you can also set boolean allow_execmem to true i believe
Yes, that makes firefox runnable again. But if possible I would prefer to have it turned off. And it does work with it turned off on the fresh install, so I guess there is some way to do it.
2011/6/18 Göran Uddeborg goeran@uddeborg.se:
Dominick Grift:
its x86_64 vs. 686 issue
x86_64 does not need execmem.
But both of these systems are x86_64 systems.
More exactly, why doesn't x86_64 need execmem? Firefox does apparently allocate memory that is both executable and writeable on x86_64 systems too.
Its the JS JIT, pre firefox4 it was only available on i686 starting with firefox4 it works on x86_64 too.
On Sat, 2011-06-18 at 22:47 +0200, Göran Uddeborg wrote:
But both of these systems are x86_64 systems.
Strange, as i never noticed this issues on any of my x86_64 systems
More exactly, why doesn't x86_64 need execmem? Firefox does apparently allocate memory that is both executable and writeable on x86_64 systems too.
Do not know, i was under the impressions that it did not need it.
you can also set boolean allow_execmem to true i believe
Yes, that makes firefox runnable again. But if possible I would prefer to have it turned off. And it does work with it turned off on the fresh install, so I guess there is some way to do it.
It is possible to silently deny this access but there are issue to take into account probably. Basically much of firefox gets run in the calling user domain "on behalf of the user". Many other applications get run in the calling user domain as well.
So if you would use "semodule -D .." to add a "dontaudit" rule to the policy database ( a rule that says deny this but do not audit the denial ) then you would potentially silently block other programs from executing writable memory as well.
So you might get into a situation where some app refuses to run and you would not find any traces of it in audit.log wrt to selinux blocking it access to execmem.
After your hints and some further investigation, I believe I've figured out why my two systems behave differently. It turns out that either allow_execmem or allow_execstack is enough for firefox to run. Since the denial was for execmem, I didn't investigate allow_execstack at first. But if I turn off both on the fresh install, I trigger the problem there too. Both were disabled on the system I upgraded.
Dominick Grift:
You can change the context of the firefox executable to execmem_exec_t
It works, and it sounds like the least intrusive change. I still have the protection on the rest of the system. I'll make a bugzilla asking if that maybe would be the default. (I guess firefox is one of the important targets for attacks though. So having to do this looses a bit of protection.)
drago01:
Its the JS JIT, pre firefox4 it was only available on i686 starting with firefox4 it works on x86_64 too.
Ah! That explains why this started to happen after the upgrade.
Dominick Grift:
Strange, as i never noticed this issues on any of my x86_64 systems
Are you running with default settings? Unless I'm mistaken, the default is for both allow_execmem and allow_execstack to be enabled, and the problem won't appear.
It is possible to silently deny this access
This is not just about an annoying alert. The denial does prevent firefox from running. Firefox crashes when it happens.
On Sun, 2011-06-19 at 10:32 +0200, Göran Uddeborg wrote:
Strange, as i never noticed this issues on any of my x86_64 systems
Are you running with default settings? Unless I'm mistaken, the default is for both allow_execmem and allow_execstack to be enabled, and the problem won't appear.
Actually i have an idea as to why i have not noticed it.
In fedora 15/16 mutter needs execmem as well. And mutter runs in the user domain (i had to allow me "staff_t" the execmem permission).
Since firefox also runs in the user domain it was automatically allowed this access as well.
It pretty much sucks and unless i confine these apps there is not much i can do.
selinux@lists.fedoraproject.org