Closed
Bug 563010
Opened 15 years ago
Closed 11 years ago
Make COW functionality accessible in the Jetpack process (without XPConnect)
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: benjamin, Assigned: mrbkap)
References
Details
Jetpack processes will use raw JSAPI, and will not have any XPCOM. We need COWs to work, though. mrbkap says that it would be that hard to separate the COW functionality out of XPConnect so that it can be used by jetpack. Could we just move it into spidermonkey directly?
Spidermonkey doesn't currently have any notion of origin, so I'm not sure it fits, and it would have to be disentangled from XPConnect anyway. Are you just looking for somewhere to put it that has the right position on our build-dep graph, or do you think that it belongs in the core engine for some reason?
Would this get better with proxies?
Reporter | ||
Comment 2•15 years ago
|
||
Not build-dep, I don't much care about that: I figured that other people might also want the functionality of exposing an object from one context to another context with the same __exposedProps__ system, perhaps with a callback which can help identify origins.
(Obviously?) Jetpack processes aren't going to share xpconnect's notion of origin anyway: there's really only two origins, jetpack and implementation.
What kind of proxies?
Assignee | ||
Comment 3•15 years ago
|
||
Shaver's talking about bug 546590. This would be about 1000000x better with proxies. Most of the shared code with XPConnect comes from the shared XPCWrapper goop, which will mostly go away with proxies (and become much easier to understand along the way).
Reporter | ||
Comment 4•15 years ago
|
||
What is the timeline for that bug? This is something we'd like to have... next week if possible.
Assignee | ||
Comment 5•15 years ago
|
||
I think gal was hoping for sometime Really Soon Now. Not sure if next week is doable for it, though.
As a note: COWs don't implicitly depend on a concept of "origins" (though, in their current incarnation, they do share some code with SOWs for completeness reasons). The underlying concepts are all based on a mostly "pure" object capabilities concept implemented in JS.
Comment 6•15 years ago
|
||
We need to label everything, always. Jetpacks should not be all lumped into one "jetpack" trust label, any more than all origins should.
Benjamin, are Jetpacks relying *only* on hand-coded correct object capabilities for security? That is a sure loser.
/be
Reporter | ||
Comment 7•15 years ago
|
||
Brendan, I'm no sure what comment #6 means. In each jetpack process there are only two trust labels, the jetpack and the jetpack implementation. See https://wiki.mozilla.org/Electrolysis/Jetpack COWs are the only way we allow jetpack->implementation calls. CPOWs will allow jetpack->content calls.
Updated•15 years ago
|
Depends on: harmony:proxies
Comment 8•15 years ago
|
||
Unless a jetpack (whether in a content process or isolated) never interact with (proxies for) objects from other trust domains than the jetpack in question, there is a problem, well-known from JS + the DOM, of unlabeled data or wrongly labeled data being an source of exploits.
What's the in-content-process jetpack security story?
/be
Comment 9•15 years ago
|
||
From IRC:
[3:04pm] brendan: there are two concerns:
[3:04pm] brendan: 1. proxy/wrapper/whatever construction must be automated from a central monitor that can see the edge-crossings that must have wrapper intercession
[3:04pm] brendan: 2. the barth/et al. concern about capability leaks and the dom access control vs. the js ocap model mean defense in depth requires always checking in the VM
brendan: i'm not sure about 2, it's a perf hit and 1 should be enuf
[3:05pm] mrbkap: Yeah. That's my first feeling as well.
/be
Reporter | ||
Comment 10•15 years ago
|
||
If there is any in-process story (there's not so far), it's using a separate single-thread runtime on a separate thread, and communicating via the same IPDL mechanism as we would for multi-process.
Comment 11•15 years ago
|
||
Then it seems to me communicating across processes should convey trust labels on the communicated objects, same as for in-process flows. This could be left to the jetpack authors but then we would lose labels in flows to an OOP jetpack and back. Security properties are end-to-end; we need to get this right whether OOP or in-process.
/be
Comment 12•15 years ago
|
||
mrbkap, mind if I reassign this to you?
Updated•15 years ago
|
Assignee: mozilla+ben → mrbkap
Assignee | ||
Comment 13•11 years ago
|
||
Believe it or not, this was fixed by compartments.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•