Closed Bug 563010 Opened 10 years ago Closed 7 years ago
Make COW functionality accessible in the Jetpack process (without XPConnect)
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?
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?
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).
What is the timeline for that bug? This is something we'd like to have... next week if possible.
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.
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
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.
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
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
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.
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
mrbkap, mind if I reassign this to you?
Believe it or not, this was fixed by compartments.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.