1196384 - (sandbox-fs) [meta] Cross-platform blockers for default-deny filesystem policy for content processes

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

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

This bug is to track everything non-OS-specific that needs to be done to Gecko or the Firefox front-end to allow desktop content processes to not have access to arbitrary files with the authority of the user running the browser.  For write access this is already solved; read access is harder, because of file:/// URLs.

resource:// and chrome:// URIs that resolve to file:/// (or jar:file:///) are covered by bug 1136836 and bug 1109293 (which might be duplicates, if the same patch could handle both of them).  There are implementation questions for this (sending the URI as-is to the parent, vs. transforming file: to remoteopenfile:), but the policy is fairly clear: any file mentioned in the registry can be read.

We also have to deal with file:/// URLs navigated to directly, or accessed from other local file content.  Bug 922481 seems to be about this, but there's not much point to “remoting” file:/// if the policy is allow-all, which it effectively has to be as far as I can tell.  There's probably no way to fix this other than by keeping local file origins and web origins in separate (sets of) content processes.  That would effectively be the desktop version of bug 1180087, and seems to depend on bug 1170894.


Individual platforms may have additional issues blocking content process filesystem isolation; for example, bug 742434 comment #18 discusses the situation on Linux.  We can file metabugs dependent on this one to cover that, if needed; I think it makes sense to leave that to the people working on each platform.

Comment 1

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

Another area covered by this bug, assuming we end up at a model with some content processes allowed to access file:/// and not used to render remote content: changes needed to ensure that a remote-content process can't take over a local-content process.  In particular, origins that can appear in both types of process (like our friends resource:// and chrome://) would need to not be treated as same-origin in ways that would allow this kind of privilege escalation.  Even with perfect sandboxing, a remote code execution vulnerability still means UXSS between any two origins that could be rendered in the same process.

Comment 2

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

(In reply to Jed Davis [:jld] {UTC-7} from comment #0)
> For write access this is already solved

I was misinformed when I wrote that.  It's not solved yet.  The blocker here appears to be printing to files (PDF or similar), which currently happens entirely in the content process.  Bug 1156742 exists for Windows, but I've confirmed that OS X and Linux are also affected.

Comment 3

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

(In reply to Jed Davis [:jld] from comment #0)
> We also have to deal with file:/// URLs navigated to directly, or accessed
> from other local file content.

…or used by add-ons in content process context; this came up as part of bug 1221148.  We've warned generally about “file I/O” on MDN, but not specifically about this.  Such cases should, I think, change to using moz-extension: or resource: or, preferably, to using DOM File objects; but we need to give add-on authors clear guidance on this topic before we commit to breaking things.

Comment 4

[The 8472]

(In reply to Jed Davis [:jld] from comment #3)
>  We've warned generally about “file I/O” on MDN

https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Which_URIs_load_where

> file: 	Always loaded in a content process.

That lead me to the conclusion that file URIs should be fine in content. Maybe the page needs clarification.

Comment 5

[Jim Mathies [:jimm]]

this meta no longer in use.