Necko: Sandboxing TCP/UDP socket in a separate process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(add TODOs section)
(to not forget appcache and tp)
 
(2 intermediate revisions by one other user not shown)
Line 13: Line 13:
== Requirements ==
== Requirements ==
=== HTTP Channel ===
=== HTTP Channel ===
* load protocol configuration from Gecko preference
* Alternative Service, uses AlternateServices.txt
* Cookie access need to stay on chrome process
* WebRequest can intercept http request/response
* Download triggered by unknown content type needs to divert back to chrome process
=== FTP Channel ===
=== FTP Channel ===
=== TCP Socket ===
=== TCP Socket ===
* permission controlled by chrome process
* prevent system port to be bind
=== UDP Socket ===
=== UDP Socket ===
* permission controlled by chrome process
* prevent system port to be bind
=== DNS ===
=== DNS ===
* permission to do system call for DNS query
* thread pool for doing blocking operation in parallel
* allow both chrome process and content process to request DNS query directly to socket process
=== Cache ===
=== Cache ===
* choice #1: stay in chrome process:
** need a copy of full http response from socket process
** for RCWN, need to delay the construction for ODA IPC endpoint until we know cache win or network win
* choice #2: move to socket process:
**  need access cache data file from socket process
** need to move cache evaluation code from nsHttpChannel to other class on socket process
=== AppCache ===
=== Tracking Protection ===
=== Proxy ===
=== Proxy ===
* load proxy configuration from Gecko preference
* PAC loading and execution, require JS runtime
* access system proxy setting
* create and connect to name pipe
=== WebSocket ===
=== WebSocket ===
=== WebRTC ===
=== WebRTC ===
=== PSM ===
* touches the preferences and various txt files in the profile
* Cert store, uses cert*.db and key*.db
* revocation information (i.e. nsICertBlocklist), uses revocations.txt
* certificate error overrides (nsICertOverrideService), uses cert_override.txt.
* HSTS/HPKP information (nsISiteSecurityService, although we've already implemented a way to access this information in non-parent processes), uses SiteSecurityServiceState.txt, SecurityPreloadState.txt
* external PKCS#11 module, require DLL loading from arbitrary file path
=== NSS ===
=== NSS ===
* uses the cert/key/secmod.db files as well as pkcs11.txt.
* access system file, e.g. /dev/urandom and system policy files under /etc
=== PKI/PKIX ===
=== PKI/PKIX ===
doesn't interact with preferences or file directly.
=== Sandboxing ===
=== Sandboxing ===
* Chrome process is still the only secure zone. Every IPC interface received at Chrome process should be audited
* 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
* 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
* Better not providing interface to create arbitrary TCP/UDP connection
=== DevTool ===
* require TCP/UDP socket
* require JS runtime for devtool protocol


== Design ==
== Design ==

Latest revision as of 18:53, 4 July 2018

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

  • load protocol configuration from Gecko preference
  • Alternative Service, uses AlternateServices.txt
  • Cookie access need to stay on chrome process
  • WebRequest can intercept http request/response
  • Download triggered by unknown content type needs to divert back to chrome process

FTP Channel

TCP Socket

  • permission controlled by chrome process
  • prevent system port to be bind

UDP Socket

  • permission controlled by chrome process
  • prevent system port to be bind

DNS

  • permission to do system call for DNS query
  • thread pool for doing blocking operation in parallel
  • allow both chrome process and content process to request DNS query directly to socket process

Cache

  • choice #1: stay in chrome process:
    • need a copy of full http response from socket process
    • for RCWN, need to delay the construction for ODA IPC endpoint until we know cache win or network win
  • choice #2: move to socket process:
    • need access cache data file from socket process
    • need to move cache evaluation code from nsHttpChannel to other class on socket process

AppCache

Tracking Protection

Proxy

  • load proxy configuration from Gecko preference
  • PAC loading and execution, require JS runtime
  • access system proxy setting
  • create and connect to name pipe

WebSocket

WebRTC

PSM

  • touches the preferences and various txt files in the profile
  • Cert store, uses cert*.db and key*.db
  • revocation information (i.e. nsICertBlocklist), uses revocations.txt
  • certificate error overrides (nsICertOverrideService), uses cert_override.txt.
  • HSTS/HPKP information (nsISiteSecurityService, although we've already implemented a way to access this information in non-parent processes), uses SiteSecurityServiceState.txt, SecurityPreloadState.txt
  • external PKCS#11 module, require DLL loading from arbitrary file path

NSS

  • uses the cert/key/secmod.db files as well as pkcs11.txt.
  • access system file, e.g. /dev/urandom and system policy files under /etc

PKI/PKIX

doesn't interact with preferences or file directly.

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

DevTool

  • require TCP/UDP socket
  • require JS runtime for devtool protocol

Design

Architecture

IPDL

Start-up Procedure

Create HTTP Channel

Create WebRTC Channel

Update Preference

Override Certificate

NTLM

TODOs

  • hook ProcessHangMonitor
  • hook CrashReporter
  • hook MemoryPresure
  • hook MemoryReporter
  • ensure Telemetry works
  • ensure MOZ_LOG works
  • remove XPCOM and support only C++ implementation