41429 - Need "blessed" DOM-accessible XPIDL interfaces

Status: VERIFIED DUPLICATE of bug 71996

(Core :: Security: CAPS, defect, P3)

Description

[David Hyatt]

The XUL DOM (and I believe the HTML DOM as well) uses XPIDL to implement some of 
the objects that are accessible via DOM calls.  On a normal Web page or XUL 
page, the security is too restrictive and access to these interfaces is denied.

Right now, popups and trees do not function in remote XUL.  This is a serious 
problem that could be solved a number of ways... perhaps the easiest being to 
bless a certain set of interfaces as being safe.

nsISidebar on the DOM window is another example.  It only works now because the 
impl happens to be in JS.  If jband ever wraps the JSOBject in an XPC wrapper, 
we'd lose the addpanel capability as well.

nominating for nsbeta2.

Comment 1

[Brendan Eich [:brendan]]

Vidur said mccabe is working on this.

/be

Comment 2

[Mitchell Stoltz (not reading bugmail)]

I talked about this with Vidur and mccabe. It seems doable though there are some 
issues to work for. We need two things: a way for each class to advertise what 
level of access should be granted to it from script, and an access control for 
instantiating XPC-wrapped objects. The first one would presumably be an interface 
on the desired class, and the second case would be an interface on its factory. 

Comment 3

[Michael La Guardia]

Marking nsbeta2-.

Comment 4

[Mike McCabe]

Attachment: interface for objects to advertise capabilities needed to access them.

Comment 5

[Mike McCabe]

Mitch and I have talked some about how to implement this... our plan is to
provide an interface that components can implement that the security manager can
check for on property access.  Methods on the interface return capability
strings; the security manager can then check that the calling script has the
needed capability before granting access.

Also needed is a similar mechanism to control creation of components and access
to services; looks like we'll need an interface that Factory objects can
implement.

Comment 6

[David Hyatt]

So the idea is that my object would implement this interface, and (if I consider 
the whole object to be safe) would just return true for all of those methods?

My only concern with this approach is that we're going to add 4 bytes to all 
security checked objects (for the extra interface).

Comment 7

[David Hyatt]

Hmmm, never mind.  I could just be sneaky and make my interface derive from the 
security check interface instead of from nsISupports.

:)

Comment 8

[vidur (gone)]

Removing nsbeta2- from the status whiteboard so that this bug can be 
reconsidered. The changes that Mike and Mitch are considering are critically 
important in that they allow us to add script-accessible features even after we 
ship Seamonkey. Drop-in components can implement the "allow-script-to-access-me" 
interface, allowing us to incrementally add script-visible features without 
doing a major revision of the product.

Comment 9

[David Hyatt]

Also be aware that non-chrome-URL XUL is starting to break left and right as i 
add more and more XPIDL interfaces to the XUL DOM.  Right now, remote XUL is in 
a very sorry state that could be easily remedied with mccabe's proposed 
solution.

Comment 10

[leger]

Checking with all PDT memebers, this looks like an arch feature.

Comment 11

[Mike McCabe]

From mail by Sean Echevarria ([e-mail])

41429 is a better general solution to the problem of scriptable access to
plugins: http://bugzilla.mozilla.org/show_bug.cgi?id=36375.  If 41429 is solved,
might want to back out the changes made to 36375 and let plugin developers know
to implement the ok-to-script-me interface.

Comment 12

[leger]

36375 is a [nsbeta2+] which has been fixed.  This bug is too risky right now.  
The PDT does not know of any seamonkey reasons or partner reasons to take this. 
Sounds cool and all, but should be targeted at the next train.  Setting to 
[nsbeta2-].

Comment 13

[vidur (gone)]

Removing the nsbeta2- designation again so it can be reconsidered *again*. There 
is little risk involved in this fix, either from a stability or a security 
perspective. As I said before, this is very important for future 
extensibility...and from Hyatt's comment it helps solve some current 
problems. Please call me if you have questions.

Comment 14

[David Hyatt]

IMO Mozilla.org should get involved here.  While PDT may not care whether or not 
remote XUL works, Mozilla.org should certainly care, and we're going to look 
pretty foolish if we put out a PR2 in which XUL widgets don't even work unless 
they're loaded as chrome URLs.

Comment 15

[Brendan Eich [:brendan]]

We aren't doing this because it's "cool" or whatever -- we're doing it to solve 
real problems faced not only by future extenders, but by current remote XUL 
users in the Mozilla community, and by plugin developers (see bug 38495 and its 
dependency, bug 32150 -- those bugs are related to this one: even when we have 
those fixed, we'll want a way for plugins to be scriptable without requiring a 
magic pref to be set).

Cc'ing ekrock for his review and input.  Eric, there's another bug (the one 
where you and Braden argued about what the default security restriction should 
be for scriptable plugins) that I'm thinking of.  I believe the solution to 
remote XUL, plugins, and XML apps may converge in this (here) bug, but I could 
be wrong.  The issues involved in trusting plugin XPConnected interfaces and 
trusting certain XBL or other interfaces seem almost identical to me.

/be

Comment 16

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 17

[Mike McCabe]

Attachment: slightly updated interface

Comment 18

[Mike McCabe]

Attachment: build new component in caps/idl; unix and windows.

Comment 19

[Mike McCabe]

Attachment: Have the security manager callback check for the interface

Comment 20

[Mike McCabe]

Added checking against nsISecurityCheckedComponent to the nsIXPCSecurityManager
implemented by the DOM script security manager.  It tries to ask the component
for a needed capability, if cheaper checks fail, and checks to see that the
calling script has that capability.

Special returned capabilities 'allaccess' and 'noaccess' unconditionally allow
or deny access.  Would it make sense to use XPCOM success values instead?

Review requested.

Comment 21

[vidur (gone)]

I reviewed the patches, made a couple of suggestions and checked in the modified 
patches for mccabe (since he's out of town). This bug will remain open, waiting 
for the nsISecurityCheckedComponentFactory interface.

Comment 22

[Mitchell Stoltz (not reading bugmail)]

Vidur, do you need the nsISecurityCheckedComponentFactory part urgently? Or can
we table this one?

Comment 23

[Mitchell Stoltz (not reading bugmail)]

Clearing [nsbeta2+] since Vidur says this is not crucial for beta2. Adding 
nsbeta3 keyword.

Comment 24

[Mitchell Stoltz (not reading bugmail)]

Clearing nsbeta3 until I hear that someone is counting on this functionality.

Comment 25

[Mike McCabe]

Marking future - not needed for nsbeta3.

Comment 26

[Mike McCabe]

Oops - putting future in the target milestone.

Comment 27

[Mike McCabe]

Adding helpwanted to keywords at Brendan's suggestion.  Any takers welcome.

Comment 28

[Mike McCabe]

removing nsbeta3 nomination.

Comment 29

[John Bandhauer]

mccabe and I say: Why not just have nsIFactory (and/or nsIModule) implement 
nsISecurityCheckedComponent if we want to do this check?

Comment 30

[John Bandhauer]

'this check' in my previous post refers to a check to allow JS callers to do 
createInstance and getService of xpcom components in addition to the mechanisms 
we now have to support making calls on components only after thay are already 
reflected into JS.

Comment 31

[Phil Schwartau]

Mass-reassigning mccabe's non-JS, non-Rhino bugs to jband (34 total). 

Would like to cc mccabe; but the mass-reassign page does not allow this. 
I'll leave it up to mccabe to decide if he wants to be cc'ed on these - 

Comment 32

[John Bandhauer]

reasigning to mstoltz. I'm not clear on what exactly we all want here.

Comment 33

[ckritzer (gone)]

QA Contact -> [e-mail]

Comment 34

[Mitchell Stoltz (not reading bugmail)]

The new security check API for the DOM will also cover any other XPIDL
interfaces that we deem safe for use by Web content.

*** This bug has been marked as a duplicate of 71996 ***

Comment 35

[James Green]

Verified dup.