Necko: Sandboxing TCP/UDP socket in a separate process: Difference between revisions
Jump to navigation
Jump to search
(initial version) |
(→Sandboxing: update requirement for sandboxing) |
||
Line 24: | Line 24: | ||
=== PKI/PKIX === | === PKI/PKIX === | ||
=== Sandboxing === | === Sandboxing === | ||
* Chrome process is still the only secure zone. Every IPC interface received at Chrome process should be audited | |||
* IPC to content process or socket process should at least do sanity check in the receiver side | |||
* Better not providing interface to create arbitrary TCP/UDP connection | |||
== Design == | == Design == | ||
=== Architecture === | === Architecture === |
Revision as of 08:04, 14 November 2017
Objectives
Move all the network and socket operations to an isolated process.
Goals
- For security
- Sandboxing network access into a separate process, preventing chrome process from opening socket
- Preventing protocol security hole to be used to control the entire browser
- For stability
- Allow recovering network layer without rebooting firefox, if crash/assertion is detected in the socket process
- For performance
- No major regression found for start-up performance and network throughput
Requirements
HTTP Channel
FTP Channel
TCP Socket
UDP Socket
DNS
Cache
Proxy
WebSocket
WebRTC
NSS
PKI/PKIX
Sandboxing
- Chrome process is still the only secure zone. Every IPC interface received at Chrome process should be audited
- IPC to content process or socket process should at least do sanity check in the receiver side
- Better not providing interface to create arbitrary TCP/UDP connection