Cross-posting to dev-tech-dom & dev-security.
As part of Electrolysis development, we need to consider the security
implications of the architecture we are implementing. Even though
security per se is not an explicit goal at this point (phase 2) of the
project, the risk remains that we could actually introduce a number of
security issues while refactoring the code into separate processes.
Some areas of risk that come to mind:
1) separating atomic security checks across IPC boundaries could
introduce security bugs from security checks failing due to
a) race conditions (ex. redirect could happen while a related
security check happens on the other side of the IPC boundary)
b) context sync issues (ex. redirects notifications may not be
propagated across IPC)
c) plugins/NPAPI may have odd behavior when in a separate process
from chrome
2) security foundation for process isolation / low rights
a) routing all network access through parent process
b) how/when can remote tabs access cookies, password manager,
certificate information, file system access for file upload/download
c) avoiding proxies for the above - don't have a generic process in
the parent process that just passes through all requests from remote
processes
d) preventing impersonation of chrome dialogs by a remote process
(to the degree feasible)
e) cache - who determines origin of documents, who writes to cache?
A larger threat model is located at https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel
. Though it is focused on security improvements from process
isolation, it should still provide useful information for laying the
foundation for future phases.
The goal is to start a discussion around the security implications of
electrolysis so please chime in, even if its with general
skepticism. :) Thanks,
Lucas.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
