On Sun, Aug 15, 2010 at 10:49 PM, Matt McCutchen <matt(a)mattmccutchen.net> wrote:
On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote:
> On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen <matt(a)mattmccutchen.net>
wrote:
> > On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
> >> But the end effect is, we're allowing a web browser to disable memory
> >> protection, exposing all users to a severe security risk from merely
> >> browsing web sites. IMHO, the performance improvements in JavaScript
aren't
> >> worth that risk.
> > An alternative is to run the JavaScript in a less-privileged process,
> > like I believe Chromium does.
>
> The "problem" is fixable there is a patch that is being discussed
> upstream to fix the issue and allow selinux memory protection it is
> just not merged yet.
I'm not holding my breath.
The patch would avoid one particularly risky behavior, but the browser
still has a very large attack surface. OS-level sandboxing is a good
idea in any case.
True, but this is not specific to javascript (jit) but the browser
itself is the number one attack vector on desktop systems, so yeah
sandboxing should indeed help.
But calls like "javascript JITs should be banned" are just nonsense.