Status
| Sandboxing of content processes | |
| Stage | Development |
| Status | In progress |
| Release target | ` |
| Health | Blocked |
| Status note | Waiting on E10S enabled by default |
{{#set:Feature name=Sandboxing of content processes
|Feature stage=Development |Feature status=In progress |Feature version=` |Feature health=Blocked |Feature status note=Waiting on E10S enabled by default }}
Team
| Product manager | Sid Stamm |
| Directly Responsible Individual | Sid Stamm |
| Lead engineer | Guillaume Destuynder |
| Security lead | Guillaume Destuynder |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Brian Bondy, David Keeler, Christoph Kerschbaumer |
{{#set:Feature product manager=Sid Stamm
|Feature feature manager=Sid Stamm |Feature lead engineer=Guillaume Destuynder |Feature security lead=Guillaume Destuynder |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Brian Bondy, David Keeler, Christoph Kerschbaumer }}
Open issues/risks
- E10S is slow going, so only slow progress can be made
- Threat model needed
Stage 1: Definition
1. Feature overview
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. While implementing sandboxing is not a goal for the current phase of Electrolysis, we need to consider the architectural requirements for doing so now in order to effectively support sandboxing in the future.
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
2. Users & use cases
- Reduce the damage for various types of vulnerabilities within Firefox. This is a defense in depth measure.
3. Dependencies
Older project description: https://wiki.mozilla.org/Security/ProcessIsolation
Early draft of threat model: https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel
4. Requirements
- Define a threat model
- Verify whether the implementation effectively mitigates the threats
Non-goals
- Eliminate security vulnerabilities. Sandboxing can reduce the severity of a given bug (by reducing the privilege the malicious code runs with), but it doesn't not actually prevent nor fix the underlying bug.
Stage 2: Design
5. Functional specification
6. User experience design
`
Stage 3: Planning
7. Implementation plan
- Land libraries to support low-rights mode for proceses
- Hook into e10s to begin lowering rights for content processes
- Iteratively remove individual rights, fix regressions, repeat
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=*E10S is slow going, so only slow progress can be made
- Threat model needed
|Feature overview=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. While implementing sandboxing is not a goal for the current phase of Electrolysis, we need to consider the architectural requirements for doing so now in order to effectively support sandboxing in the future.
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
|Feature users and use cases=* Reduce the damage for various types of vulnerabilities within Firefox. This is a defense in depth measure.
|Feature dependencies=Older project description: https://wiki.mozilla.org/Security/ProcessIsolation
Early draft of threat model: https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel
|Feature requirements=* Define a threat model
- Verify whether the implementation effectively mitigates the threats
|Feature non-goals=* Eliminate security vulnerabilities. Sandboxing can reduce the severity of a given bug (by reducing the privilege the malicious code runs with), but it doesn't not actually prevent nor fix the underlying bug. |Feature functional spec=Security/Sandboxing |Feature ux design=` |Feature implementation plan=* Land libraries to support low-rights mode for proceses
- Hook into e10s to begin lowering rights for content processes
- Iteratively remove individual rights, fix regressions, repeat
|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | Product Hardening |
| Roadmap | Security |
| Secondary roadmap | Platform |
| Feature list | ` |
| Project | ` |
| Engineering team | Security |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=Product Hardening |Feature roadmap=Security |Feature secondary roadmap=Platform |Feature list=` |Feature project=` |Feature engineering team=Security }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}
Chrome already does something similar. See http://dev.chromium.org/developers/design-documents/sandbox
Microsoft also had a research project for a multi-principal browser: http://research.microsoft.com/apps/pubs/default.aspx?id=79655