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

Notes from my discussion with jlebar:

  browser:
    permission failure leads to regular iframe
    child-only check for creating browser, no real way to ensure permission is actually granted
    maybe necko can check to see that all isBrowser==true loads have that permission? not escalation of privilege
    possible to assert browser permission in parent at TabParent::RecvBrowserFrameOpenWindow!

We should investigate what we can do with necko and at least add a check in RecvBrowserFrameOpenWindow

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

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

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

I have no idea where all this code lives.
Justin can you take this?

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

(In reply to Gregor Wagner [:gwagner] from comment #2)
> I have no idea where all this code lives.
> Justin can you take this?

This falls pretty low on the list of priorities I have on my plate; I probably wouldn't be able to get to it for a while.

But I'm actually not sure what it is that we're trying to protect here.  The window opened has the same traits (is-browser, app-id, etc) as the opener; that's enforced.  I can't think of any circumstances under which we'd deny permission to open a window.

So maybe this is just invalid.

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

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

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

(In reply to Justin Lebar [:jlebar] from comment #3)
> (In reply to Gregor Wagner [:gwagner] from comment #2)
> > I have no idea where all this code lives.
> > Justin can you take this?
> 
> 
> So maybe this is just invalid.

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

(In reply to Justin Lebar [:jlebar] from comment #3)
> So maybe this is just invalid.

Well, if an app gets browser permissions somehow then the principals it sends to necko will all have isBrowser=true on them, right? What could get screwed up if that happens?

Wasn't there something just the other day about blanket-granting geolocation privs to isBrowser pages? That might not be what we're going to end up doing, but I guess that's an example of the type of thing I'm thinking of.

	Alex Keybl [:akeybl]
	Comment 7 • 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 8 • 12 years ago

(In reply to ben turner [:bent] from comment #0)
> Notes from my discussion with jlebar:
> 
>   browser:
>     permission failure leads to regular iframe

This seems fine.

>     child-only check for creating browser, no real way to ensure permission
> is actually granted

As far as I can tell there is no way to enforce this since this is just logic happening in the child process.

>     maybe necko can check to see that all isBrowser==true loads have that
> permission? not escalation of privilege

This is bug 782542.

>     possible to assert browser permission in parent at
> TabParent::RecvBrowserFrameOpenWindow!

This call isn't related to "browser" permission stuff as far as I can tell. This simply happens in response to the child process calling window.open.

My interpretation is that there's nothing that needs to happen related to the "browser" permission itself. Similar to the "embed-apps" permission. Instead we just need to implement appropriate security checks in the other features that we have, like IndexedDB and Necko, to ensure that we don't leak data to a child process that shouldn't have access to it.