563010 - Make COW functionality accessible in the Jetpack process (without XPConnect)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Benjamin Smedberg]

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?

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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?

Comment 2

[Benjamin Smedberg]

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?

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

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).

Comment 4

[Benjamin Smedberg]

What is the timeline for that bug? This is something we'd like to have... next week if possible.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

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

[Brendan Eich [:brendan]]

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

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Brendan Eich [:brendan]]

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

[Brendan Eich [:brendan]]

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

Comment 10

[Benjamin Smedberg]

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

[Brendan Eich [:brendan]]

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

[Ben Newman (:bnewman) (:benjamn)]

mrbkap, mind if I reassign this to you?

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Believe it or not, this was fixed by compartments.