1109293 - Desktop content process resource:// URIs should not directly use file:///

Status: RESOLVED INVALID

(Core :: Networking, defect, P3)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Desktop content processes appear to use resource:// URIs that resolve to direct file:// accesses.  This complicates sandboxing, but it's not insurmountable — for example, on Linux with seccomp-bpf, we can intercept the open(2) system call and run userspace code to communicate with an out-of-process broker instead.

However, on B2G, app:// URIs are implemented as jar:remoteopenfile://, which uses our IPC framework to ask the parent process to open the application.zip files, because the content process does not have direct access to them.  This higher-level, cross-platform approach may be preferable.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Adjusting the subject because this doesn't need to specifically use remoteopenfile:.  What's needed is that when a mapping is added to a SubstitutingProtocolHandler in the parent, that's messaged to the child process in such a way that the child's corresponding SubstitutingProtocolHandler resolves it to a URI that works in the child (i.e., isn't file: or a nested scheme with an inner file:).  This is complicated by the fact that these can map arbitrary filesystem subtrees, if I understand correctly, so just passing a capability for a single file isn't enough.

So, one possibility would be to change file: to remoteopenfile: and maintain a collection of all the file: paths currently present as destinations of resource URI mappings, and do subtree checks (and make sure not to allow pathname traversal with any variant of "..").  I don't know how performance-sensitive this is — i.e., if just iterating over the entire substitution map each time would be too much.   It's already going to need an IPC round-trip for each open, so it might not be.  (Side note: changing or removing a mapping can race with the child trying to use it, so receiving an unrecognized path wouldn't necessarily mean the child is malicious.)

But the child process doesn't need the absolute paths, as long as it has some identifier to reference the grant of filesystem access; the blob: scheme uses UUIDs for this (but only for individual files, and the interface to it from C++ is… not simple).  That might not enable any solutions that are easier than remoteopenfile:, but it's worth keeping in mind.

For reference, the IPC here seems to be PContent::RegisterChrome{,Item}, which ultimately deals with the SerializedURI type defined in chrome/RegistryMessageUtils.h.