12:34 p.m.
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)
12:38 p.m.
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
3:47 p.m.
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.
3:51 p.m.
2011/6/18 Göran Uddeborg <goeran(a)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.
3:54 p.m.
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.
3:32 a.m.
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.
3:46 a.m.
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.
4711
days inactive
4712
days old
selinux@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Dominick Grift -
drago01 -
Göran Uddeborg