Security/ProcessIsolation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Process Isolation =
Process isolation is designed to separate Firefox into multiple processes, each with the least amount of privilege necessary.  In doing so, the potential damage for a large number of Firefox vulnerabilities can be reduced.
 
Process isolation is designed to separate Firefox into multiple processes, each with the least amount of privilege necessary.  In doing so, the potential damage for a large number of Firefox vulnerabilities can be mitigated.


== Project Goals ==
== Project Goals ==


Reduce the damage for various types of vulnerabilities within Firefox.  This is a defense in depth measure.
Reduce the damage for various types of vulnerabilities within Firefox.  This is a defense in depth measure.
We will do so by:
* identifying high level of categories of threats that we could address via process isolation
* determining the architectural implications of mitigating each category
* selecting a threat model and architecture that will address it, and prototyping it
* determining whether the chosen model is actually feasible within the current Gecko architecture
* implementation roadmap
* implement it


== Roadmap ==
== Roadmap ==


* Put together a team of people willing to put in a sustained effort on process isolation (6+ month timeframe)
* Put together a team of people willing to put in a sustained effort on process isolation design and prototyping (6+ month timeframe)
* Identify broad sets of vulnerabilities that might be mitigated by process isolation (high level threat model)
* Identify broad sets of vulnerabilities that might be mitigated by process isolation (high level threat model, here: [[Security/ProcessIsolation/ThreatModel]]
* Identify several potential architectures.  A few that come to mind, there will be more:
* Identify several potential architectures.  A few that come to mind, there will be more:
** Isolate entire Firefox process into low rights mode (sensitive I/O virtualized or brokered).  Protects system from browser vulns but does not provide stability or inter-domain security.
** Isolate entire Firefox process into low rights mode (sensitive I/O virtualized or brokered).  Protects system from browser vulns but does not improve stability or inter-domain security.
** Isolate Firefox into multiple processes (process per tab or process per top-level).  Provides system protection, and stability benefits, but minimal inter-domain protections.
** Isolate Firefox into multiple processes (process per tab or process per top-level).  Provides system protection, and stability benefits, but minimal inter-domain protections.
** Isolate Firefox into separate process per domain.  The most complex model, but provides system protection, stability, and inter-domain compartmentalization.
** Isolate Firefox into separate process per domain.  The most complex model, but provides system protection, stability, and inter-domain compartmentalization.
Line 20: Line 27:
* Develop a detailed threat model to understand how threats will be mitigated and where we might run into implementation problems for the given architecture
* Develop a detailed threat model to understand how threats will be mitigated and where we might run into implementation problems for the given architecture
* Figure out how to address any design or implementation issues discovered
* Figure out how to address any design or implementation issues discovered
* Iterative the above 3 steps
* Iterative the above 3 steps as necessary
* Implementation roadmap
** Identify components affected and respective developers
** Figure out milestones and beta requirements
** Budget and schedule for external security review

Latest revision as of 17:13, 29 April 2009

Process isolation is designed to separate Firefox into multiple processes, each with the least amount of privilege necessary. In doing so, the potential damage for a large number of Firefox vulnerabilities can be reduced.

Project Goals

Reduce the damage for various types of vulnerabilities within Firefox. This is a defense in depth measure.

We will do so by:

  • identifying high level of categories of threats that we could address via process isolation
  • determining the architectural implications of mitigating each category
  • selecting a threat model and architecture that will address it, and prototyping it
  • determining whether the chosen model is actually feasible within the current Gecko architecture
  • implementation roadmap
  • implement it

Roadmap

  • Put together a team of people willing to put in a sustained effort on process isolation design and prototyping (6+ month timeframe)
  • Identify broad sets of vulnerabilities that might be mitigated by process isolation (high level threat model, here: Security/ProcessIsolation/ThreatModel
  • Identify several potential architectures. A few that come to mind, there will be more:
    • Isolate entire Firefox process into low rights mode (sensitive I/O virtualized or brokered). Protects system from browser vulns but does not improve stability or inter-domain security.
    • Isolate Firefox into multiple processes (process per tab or process per top-level). Provides system protection, and stability benefits, but minimal inter-domain protections.
    • Isolate Firefox into separate process per domain. The most complex model, but provides system protection, stability, and inter-domain compartmentalization.
  • Determine which sets of vulnerabilities could be addressed by different architectures
  • Outline any operating system limitations and feasibility of each potential architecture on major OSes
  • Pick a (straw man) architecture
  • Develop a detailed threat model to understand how threats will be mitigated and where we might run into implementation problems for the given architecture
  • Figure out how to address any design or implementation issues discovered
  • Iterative the above 3 steps as necessary
  • Implementation roadmap
    • Identify components affected and respective developers
    • Figure out milestones and beta requirements
    • Budget and schedule for external security review