SecurityEngineering/Jan2013WorkWeek/08-Sandboxing

1/16 at 2:30pm

Sandboxing

Session Lead: Ian

No Recording

• https://wiki.mozilla.org/Features/Security/Low_rights_Firefox
• https://intranet.mozilla.org/User:Imelven@mozilla.com/Sandboxing

Imposing additional restrictions on what a process can do.

Why? What if Fx gets compromised and all our protections get compromised? This limits what a successful exploit can do.

e10s: separating chrome and content (plus IPC). But synchronous UI elements and add-ons.  :( And this is painful on mobile (and overall perf degradation). This might break add-ons: things that require privs that low-rights Firefox doesn't have.

Big question: Will this thwart many attacks? There are Firefox exploits being brokered (as opposed to plugins). Firefox is a target because there are *targeted* attacks and many targets use Firefox. More countermeasures like sandboxing will make exploits harder to create.

This would not be an insignificant investment (lots of engineering work). Needs planning too.

Firefox on Metro is a good starting point for PoC because there are no add-ons or plugins, and there is multi-process stuff going on. Probably starting there with a PoC.

Most add-ons don't want to start processes.

What are we trying to protect?

• Browser's data from the browser exe?
• The rest of the OS from the browser?
• ...

How good is good enough? What is secure enough? Can we get by with the two-process model? Is anything better than nothing?

One way to prioritize: find out where the worst privilege escalation bugs exist and sandbox those things first.