Closed
Bug 814150
Opened 12 years ago
Closed 12 years ago
Need additional security checks for the "browser" permission
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
People
(Reporter: bent.mozilla, Unassigned)
References
Details
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
Updated•12 years ago
|
blocking-basecamp: ? → +
Comment 1•12 years ago
|
||
Gregor, Doug said you should be the lucky owner of this bug. Congrats! :)
Assignee: nobody → anygregor
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.
Comment 4•12 years ago
|
||
Setting priority based on triage discussions. Feel free to decrease priority if you disagree.
Priority: -- → P1
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.
Flags: needinfo?(bent.mozilla)
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.
Flags: needinfo?(bent.mozilla)
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.
Target Milestone: --- → B2G C3 (12dec-1jan)
(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.
Assignee: anygregor → nobody
blocking-basecamp: + → -
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•