Hacker News Reader

Comment by ryuuchin | Hacker News Reader

Moving to a multi-process architechture has a number of benefits but security is certainly one of them.

While currently it doesn't really add anything from a security perspective the ability to run rendering in a separate process will allow it to very naturally support a number of operating system mitigations that it otherwise would not have in addition to adding restrictions on the process itself (sandboxing).

I believe this will allow Firefox to start to adapt to a more defense in depth philosophy although I admit it's probably still a long way to actually getting there. There's no getting around the fact that security in Firefox has been rather stale but e10s gives something to look forward too since the multi-process architecture allows you to do so much more for defense in depth.

View on HN

True. If running Firefox in Linux, I'd also recommend to use application sandboxing facilities provided by the kernel.

For example, with Firejail [1] (completely unrelated to Firefox) one can do firejail <application> to run a sandboxed instance. Firejail comes bundled with rules for many applications to limit the files they can view from each sandboxed container. In case of a security breach, that keeps data leaks under control. E.g., an attacker might be able to steal stuff from your Firefox instance, but not from your home directory.

[1] https://firejail.wordpress.com/

I think you can do some things with chroots[1] that you otherwise couldn't although I could be wrong. My knowledge on Chrome's linux sandboxing (just for comparison) is kind of limited. I'm sure there are other protections such as seccomp which you can heavily restrict in renderer processes that you otherwise couldn't.

[1] With grsecurity they can become much more chroot-jail like. Chrome uses chroot's I believe so it's very beneficial there.

Honestly, I can't really come up with one reason that would make a multi-process Firefox more secure than a single-process one.

The multi-process trend is sold as "crash-proof" which reads like "can't fix exception handling".

Did you not think of sandboxing?

Multi-process is not crash proof, it contains any code execution vulnerabilities to the process that hit the edge case in question.

With multiple processes you can apply more strict OS controls to one of the processes. That doesn't work with threads.

Which are ...?

See the problem is always local code execution. Once you have that, it's over. There are real mitigations (W^X, ASLR, stack cookies) and then there seems to be lore ("multi-process", "sandboxing").

> Which are ...?

I'm not an expert, but I wonder if this means you could restrict GPU access to the master process only (for the sake of hardware-accelerated compositing) without needing to expose it to the website-facing process (due to the security vulnerabilities in GPU drivers).

Angle (the OpenGL -> DirectX thingy) actually acts as a sanitizer for GPU commands so in a sense browsers which use Angle already have some protection over this. While I think complete protection is impossible through the use of Angle and GPU process I think you reduce it as much as you can since you can't control the driver itself aside from what protections Windows gives you by default.

That implies running Windows, though.

My biggest problem with GPU drivers is that they stick out like a sore thumb on a hardened system. All the protection and isolation in the world won't help you when you have a stock-compiled, PaX-disabled blob loaded into your binary that communicates directly with the kernel.

For this reason and this reason alone, I am forced to basically limit OpenGL access to X.org and mpv.

> That implies running Windows, though.

Indeed. My knowledge on Linux is pretty limited but I seem to remember that Nvidia fixed something which let you use Pax/grsecurity protections you otherwise couldn't. This still implies loading a binary blob but certain kernel protections could still help you IIRC (DEP?). I could be misremembering. I can't check since grsecurity set their twitter to protected.

I'm not sure what Chrome does aside from having a separate GPU process and whether or not any sanitizing takes place. They're pretty good with stuff like that so it would surprise me if some amount of protection wasn't offered.

Edit: There are some patches from the Pax folks for Nvidia drivers which I believe help with PAX_USERCOPY[1][2]? Although that may just be for getting it working...

[1] https://grsecurity.net/~paxguy1/

[2] https://grsecurity.net/~paxguy1/nvidia-drivers-367.35-pax.pa... (example)

Those patches are for running the nvidia kernel driver in a PaX-enabled kernel. It doesn't help you protect the actual libGL.so, which my concern was about.

(Indeed, I have to use those patches otherwise the nvidia kernel module wouldn't compile)

> Which are ...?

seccomp.

Local code execution doesn't mean a thing (except for wasted CPU cycles and/or memory) if number of syscalls the process can do is limited to the bare minimum.

And the Windows equivalent (win32k lockdown)[1]. This restricts a number of win32k syscalls including all GDI ones. Chrome already uses this mitigation for renderer processes and has support for PPAPI plugin processes on their dev/beta channels.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh8...

Sandboxing absolutely does reduce attack surface, and that isn't just "lore". Nobody in the security field considers W^X superior to kernel-enforced sandboxing.

> There are real mitigations (W^X, ASLR, stack cookies)

We've had these for nearly a decade with other software. Have they completely stopped bugs/exploits in that time?

I'm not trying to take away from the usefulness of those mitigations against certain classes of exploits but the point of "lore" such as sandboxing is to promote defense in depth. If there's a buffer overflow which is exploitable then containing that in a restricted sandbox with no permissions to do anything requires more work to break out of.

Reply on news.ycombinator.com