1853706 - Introduce a new Principal-bound/StorageKey-bound parent actor PBoundStorageKey (name TBD) to replace PBackground as the manager of storage-related APIs

Status: NEW

(Core :: DOM: Content Processes, enhancement, P3)

Description

[Andrew Sutherland [:asuth] (he/him)]

Currently many storage-related APIs send PrincipalInfo/nsIPrincipal payloads along with their requests to identify the origin/global they are operating on behalf of. This creates extra complexity from a security perspective because we end up needing to validate these values. This bug formalizes an ongoing discussion we've had about how best to bind the principal / StorageKey (bug 1776271) so that principal validity is established inductively and resembles an object capability model where the entity taking the action to create the global can inductively propagate or specialize its existing authority. This would help address the high level goal of the fission-ipc-map Bug 1491018.

This implementation could allow, or even be coordinated with, work proposed on bug 1524025 to split uses of PBackground into multiple background threads rather than a single thread. The basics of this may just happen for free since using the cheap-and-easy endpoint mechanism may be the easiest way to provide for the object capability idiom.

Approach per global

In terms of the specific globals we expose storage-related APIs for and potential implementation approaches, we have:

• Window Globals: We can use PWindowGlobal which explicitly is associated with a principal.
• DedicatedWorker: We inductively have the creator of the worker's global. Because dedicated workers can be created by both windows and workers it likely makes sense to use the PBoundStorageKey protocol as the basis for minting a new one for the new worker. It's also worth noting that PBackground on a worker could already inherently be bound to a given principal[1], but given the low cost of creating new actors, it seems better to create a new actor type rather than add more cruft to the PBackground impl, especially because main-thread users of PBackground are not constrained to a single principal.
• SharedWorker: The decision to actually spin up a SharedWorker via the RemoteWorker mechanism is made in the parent process in response to a request made over PBackground. We would move the request to PBoundStorageKey which provides the inductive global propagation we desire. We could also send a PBoundStorageKey endpoint to the content process where we are requesting the worker be created.
• ServiceWorker: These also use the RemoteWorker mechanism, except the ServiceWorkerManager owns the spawned worker and wouldn't have inductive access to an existing PBoundStorageKey because ServiceWorker interception happens in the load process before a global is created. The endpoint mechanism would still work here.
• non-window main-thread globals (BackstagePass, SandboxPrivate, maybe some others): This is potentially a little more ugly and requires more investigation, but most significantly we're just looking at a bunch of system-principaled globals either propagating the system principal or maybe creating web-extension content script globals. I'm speaking fuzzily from memory, but I believe the web-extension content script sandboxes don't necessarily get storage access of their own (unless they are the background page/SW), which potentially simplifies things. A potential rough draft:
  • The parent process is able to mint a trusted system principal PBoundStorageKey at startup.
  • All content processes get a trusted (for the privileged about process) or untrusted[2] system principal (all other content processes) minted in the parent process and sent down to them over PContent.
  • Those system PBoundStorageKeys either get stored in a static that we only use if a non-window global has the system principal or a slot on each nsIGlobalObject subclass which BackstagePass starts out with and that we conditionally propagate into other globals as we create them if we're creating them with the system principal.

1: Worker globals do have a separate debugger global which does not have its own PBackground. This doesn't matter too much because the debugger logic in the worker does not/should not try and use any storage-related APIs. It is just a glue layer for the same-thread-only debugger API.

2: In talking with :nika, we've discussed how there ideally would be a distinction between the system principal in processes we trust (parent process, probably the privileged about process) and the system principal in processes we don't trust. It seems like it would make sense to capture this distinction, as we already do make policy decisions in this space, at least for SharedWorkers.

Relationship to the Clients API

Although in the fission-ipc-map bug I have previously proposed involving the clients API in authority checks, in my proposal here the Clients API would not have a special status and would simply be another API whose protocols move from PBackground to PBoundStorageKey.

Authority would start from BackstagePass, PWindowGlobal, or the RemoteWorker subsystem and its consumers. And it continues to be our plan to move RemoteWorker coordination to happen on the main thread more directly interacting with the ContentParent instances and their infrastructure.