All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED INVALID

Status

()

P3
normal
RESOLVED INVALID
4 years ago
a year ago

People

(Reporter: jld, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog], sb+)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

3 years ago
Blocks: 1196384
(Reporter)

Comment 1

3 years ago
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.
See Also: → bug 1136836
Summary: Desktop content process resource:// URIs should use remoteopenfile:// → Desktop content process resource:// and moz-extension:// URIs should not directly use file:///
Whiteboard: [necko-backlog]

Updated

2 years ago
Whiteboard: [necko-backlog] → [necko-backlog][sb?]

Updated

2 years ago
Flags: needinfo?(jmathies)
(Reporter)

Updated

2 years ago
Blocks: 1288874

Updated

2 years ago
Flags: needinfo?(jmathies)

Updated

2 years ago
Whiteboard: [necko-backlog][sb?] → [necko-backlog][sbwc2]

Updated

2 years ago
Whiteboard: [necko-backlog][sbwc2] → [necko-backlog][sbwc3]

Updated

a year ago
Whiteboard: [necko-backlog][sbwc3] → [necko-backlog], sb?

Updated

a year ago
Blocks: 922481
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Summary: Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// → Desktop content process resource:// URIs should not directly use file:///

Updated

a year ago
Priority: -- → P3
Whiteboard: [necko-backlog], sb? → [necko-backlog], sb+
You need to log in before you can comment on or make changes to this bug.