Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Description • 12 years ago

Talking with jlebar we realized that there are only child process checks for this permission. We could maybe fix this by restricting app:// loads in the parent through necko?

	Andrew Overholt [:overholt]
	Comment 1 • 12 years ago

Gregor, Doug said you should be the lucky owner of this bug.  Congrats!  :)

	Andrew Overholt [:overholt]
	Comment 2 • 12 years ago

Setting priority based on triage discussions.  Feel free to decrease priority if you disagree.

	Gregor Wagner [:gwagner]
	Comment 3 • 12 years ago

(In reply to ben turner [:bent] from comment #0)
> Talking with jlebar we realized that there are only child process checks for
> this permission. We could maybe fix this by restricting app:// loads in the
> parent through necko?

I am not the right person here.

	Alex Keybl [:akeybl]
	Comment 4 • 12 years ago

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 5 • 12 years ago

I don't know what checks we could do in the parent process other than the ones we already do (or have bugs filed on)?

app:// should already be restricted. (Actually, right now it's too restricted, see bug 813468 and bug 815523).

IndexedDB is already working. There's no way a child process can "embed" another app and somehow get access to that apps IndexedDB data.

Likewise, bug 782542 should ensure that a child process never gets access to the cookies of another app.

What we might need is checks in the parent process for the browser API itself? In particular we need to make sure to never modify the information about which appids are running in a child process without ensuring that the currently contained app has "embed-apps". Actually, right now it should never change since we don't have nested child processes.

Is that what's needed here?

	Justin Lebar (not reading bugmail)
	Comment 6 • 12 years ago

Recalling my conversation with bent, I was worried about the fact that the only check of the embed-apps permission comes from nsGenericHTMLFrameElement::GetAppManifestURL (in the child).

I think we'd probably be safe if we don't allow nested content processes.  But we also only do nested-content-process checks in the child (nsFrameLoader::ShouldLoadRemoteProcess).  :)

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 7 • 12 years ago

Security-wise it seems totally ok if the child process spawns a new child process. If the child process spawns a grand-child process, that grand-child process wouldn't have the permission to do anything that the child process couldn't do.

In fact, anything that the grand-child process wanted to do, it would have to do by proxying calls to the child process which proxies them to the parent process. And so the exact same checks that protect us from a rogue child process, should protect us from a rogue grand-child process.

Please do reopen if I'm wrong.