Bug 326715 – Firefox / hardened Gentoo: plugin-container needs paxctl -m, firefox shouldn't

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Klaus Kusche 2010-07-03 08:11:43 UTC]

On a hardened Gentoo system with PaX enabled, /usr/lib64/xulrunner-1.9.2/plugin-container needs paxctl -m. Otherwise, the plugin-container will be killed immediately by PaX when loading the adobe flash plugin or Java.

However, as plugins now run in plugin-container and no longer directly in firefox, it should be possible (and highly recommended for security reasons) to compile firefox itself in a way which doesn't need paxctl -m any longer, and to install the firefox executable without paxctl -m.
(see discussion in bug 278698, #34 and following, especially #37)

[Comment 1 Jory A. Pratt 2010-08-05 02:34:08 UTC]

(In reply to comment #0)
> On a hardened Gentoo system with PaX enabled,
> /usr/lib64/xulrunner-1.9.2/plugin-container needs paxctl -m. Otherwise, the
> plugin-container will be killed immediately by PaX when loading the adobe flash
> plugin or Java.
> 
> However, as plugins now run in plugin-container and no longer directly in
> firefox, it should be possible (and highly recommended for security reasons) to
> compile firefox itself in a way which doesn't need paxctl -m any longer, and to
> install the firefox executable without paxctl -m.
> (see discussion in bug 278698, #34 and following, especially #37)
> 
I am happy to accomidate you with plugin-container, but changing firefox is not gonna happen. It is needed for most javascript as it is nothing but xulrunner renamed and copied into applications folder.

[Comment 2 Jory A. Pratt 2010-08-06 13:49:02 UTC]

Fixed in xulrunner-1.9.2.8-r1. Leaving open in case hardened team still wants/needs.

[Comment 3 PaX Team 2010-08-26 10:06:38 UTC]

(In reply to comment #1)
> I am happy to accomidate you with plugin-container, but changing firefox is not
> gonna happen. It is needed for most javascript as it is nothing but xulrunner
> renamed and copied into applications folder.

well, javascript.options.jit.{chrome,content} let one disable the JIT compiler engine, would that enable running FF with MPROTECT on?

[Comment 4 Klaus Kusche 2010-09-05 11:09:08 UTC]

I'll try if nobody else does, but it will take some time
(I'm just moving my home from Austria to Germany, 
there are more urgent things to do now...)

[Comment 5 Klaus Kusche 2010-09-11 10:33:14 UTC]

Works for me. Just tried a dozen pages with both jit options set to false
and MPROTECT enabled, didn't have any problems.

However, you *first* have to set the options to false
(with MPROTECT disabled) and then reenable MPROTECT:
With MPROTECT enabled and jit still true,
firefox doesn't even come up, so you can't edit about:config.

[Comment 6 PaX Team 2010-09-11 15:24:52 UTC]

(In reply to comment #5)
> Works for me. Just tried a dozen pages with both jit options set to false
> and MPROTECT enabled, didn't have any problems.

any benchmark results perhaps so users know what the tradeoff is? ;)

[Comment 7 Klaus Kusche 2010-09-11 15:38:52 UTC]

Could you send me some Javasoft benchmark URL's?

I'm on a fast machine, I didn't notice any differences for pages using
just a little bit of JavaScript...

[Comment 8 PaX Team 2010-09-22 12:27:54 UTC]

(In reply to comment #7)
> Could you send me some Javasoft benchmark URL's?
> 
> I'm on a fast machine, I didn't notice any differences for pages using
> just a little bit of JavaScript...

this one was recently released: http://krakenbenchmark.mozilla.com/index.html

[Comment 9 Klaus Kusche 2010-10-03 12:12:21 UTC]

Tried it.
About a factor 6 in speed: 
73249.8 ms compared to 12591.4 ms, both +- 3 %.
Individual tests ranging from same speed to a factor of 15.

I'm more worried about the difference in memory:
Without jit, firefox grew to just below 8 GB vsize,
with jit, max. vsize was just above 2 GB.

[Comment 10 Dillon 2010-11-22 00:56:36 UTC]

(In reply to comment #5)
> Works for me. Just tried a dozen pages with both jit options set to false
> and MPROTECT enabled, didn't have any problems.
> 
> However, you *first* have to set the options to false
> (with MPROTECT disabled) and then reenable MPROTECT:
> With MPROTECT enabled and jit still true,
> firefox doesn't even come up, so you can't edit about:config.

Add the lines to /usr/lib/firefox/defaults/preferences/firefox-nojit.js

pref("javascript.options.jit.content", false);
pref("javascript.options.jit.chrome", false);

as opposed to user_pref; Now you won't have to cycle MPROTECT every time you add a new profile to firefox or use the useradd command.

(In reply to comment #1)
> (In reply to comment #0)
> > On a hardened Gentoo system with PaX enabled,
> > /usr/lib64/xulrunner-1.9.2/plugin-container needs paxctl -m. Otherwise, the
> > plugin-container will be killed immediately by PaX when loading the adobe flash
> > plugin or Java.
> > 
> > However, as plugins now run in plugin-container and no longer directly in
> > firefox, it should be possible (and highly recommended for security reasons) to
> > compile firefox itself in a way which doesn't need paxctl -m any longer, and to
> > install the firefox executable without paxctl -m.
> > (see discussion in bug 278698, #34 and following, especially #37)
> > 
> I am happy to accomidate you with plugin-container, but changing firefox is not
> gonna happen. It is needed for most javascript as it is nothing but xulrunner
> renamed and copied into applications folder.
> 
I don't see why this couldn't be done with a USE flag though it might be considered as improper due to how your are simply flipping a preference option.

[Comment 11 Jory A. Pratt 2010-12-30 03:40:54 UTC]

If mozilla team is needed later please re-add us, we will be more then happy to take a patch.

[Comment 12 Klaus Kusche 2013-02-24 10:10:38 UTC]

Current versions are fine.