1.70 KB, patch
|Details | Diff | Splinter Review|
1.91 KB, text/plain
1.00 KB, patch
|Details | Diff | Splinter Review|
6.48 KB, patch
|Details | Diff | Splinter Review|
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.
Vidur said mccabe is working on this. /be
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Created attachment 9901 [details] [diff] [review] interface for objects to advertise capabilities needed to access them.
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.
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).
Hmmm, never mind. I could just be sneaky and make my interface derive from the security check interface instead of from nsISupports. :)
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.
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.
Checking with all PDT memebers, this looks like an arch feature.
Whiteboard: [NEED INFO]
From mail by Sean Echevarria (firstname.lastname@example.org) 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.
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-].
Whiteboard: [NEED INFO] → [nsbeta2-]
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.
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.
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
Putting on [nsbeta2+] radar for beta2 fix.
Created attachment 10497 [details] [diff] [review] build new component in caps/idl; unix and windows.
Created attachment 10498 [details] [diff] [review] Have the security manager callback check for the interface
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.
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.
Vidur, do you need the nsISecurityCheckedComponentFactory part urgently? Or can we table this one?
Clearing [nsbeta2+] since Vidur says this is not crucial for beta2. Adding nsbeta3 keyword.
Keywords: nsbeta2 → nsbeta3
Clearing nsbeta3 until I hear that someone is counting on this functionality.
Assignee: mstoltz → mccabe
Status: ASSIGNED → NEW
Marking future - not needed for nsbeta3.
Oops - putting future in the target milestone.
Target Milestone: M18 → Future
Adding helpwanted to keywords at Brendan's suggestion. Any takers welcome.
removing nsbeta3 nomination.
mccabe and I say: Why not just have nsIFactory (and/or nsIModule) implement nsISecurityCheckedComponent if we want to do this check?
'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.
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 -
Assignee: mike+mozilla → jband
reasigning to mstoltz. I'm not clear on what exactly we all want here.
Assignee: jband → mstoltz
Component: XPConnect → Security: CAPS
QA Contact -> email@example.com
QA Contact: rginda → ckritzer
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.