Need "blessed" DOM-accessible XPIDL interfaces

VERIFIED DUPLICATE of bug 71996

Status

()

P3
normal
VERIFIED DUPLICATE of bug 71996
19 years ago
18 years ago

People

(Reporter: hyatt, Assigned: security-bugs)

Tracking

({arch, helpwanted})

Trunk
Future
x86
Windows 98
arch, helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Keywords: 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

Comment 3

19 years ago
Marking nsbeta2-.
Whiteboard: [nsbeta2-]

Comment 4

19 years ago
Created attachment 9901 [details] [diff] [review]
interface for objects to advertise capabilities needed to access them.

Comment 5

19 years ago
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.
(Reporter)

Comment 6

19 years ago
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).
(Reporter)

Comment 7

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

:)

Comment 8

19 years ago
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.
Whiteboard: [nsbeta2-]
(Reporter)

Comment 9

19 years ago
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

19 years ago
Checking with all PDT memebers, this looks like an arch feature.
Whiteboard: [NEED INFO]

Comment 11

19 years ago
From mail by Sean Echevarria (sechevarria@beatnik.com)

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

19 years ago
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-]

Comment 13

19 years ago
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.
Whiteboard: [nsbeta2-]
(Reporter)

Comment 14

19 years ago
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
Keywords: arch

Comment 16

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Comment 17

19 years ago
Created attachment 10496 [details]
slightly updated interface

Comment 18

19 years ago
Created attachment 10497 [details] [diff] [review]
build new component in caps/idl; unix and windows.

Comment 19

19 years ago
Created attachment 10498 [details] [diff] [review]
Have the security manager callback check for the interface

Comment 20

19 years ago
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

19 years ago
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
Whiteboard: [nsbeta2+]
Clearing nsbeta3 until I hear that someone is counting on this functionality.
Assignee: mstoltz → mccabe
Status: ASSIGNED → NEW
Keywords: nsbeta3

Updated

19 years ago
Keywords: nsbeta3

Comment 25

19 years ago
Marking future - not needed for nsbeta3.
Whiteboard: future

Comment 26

19 years ago
Oops - putting future in the target milestone.
Target Milestone: M18 → Future

Updated

19 years ago
Keywords: helpwanted

Comment 27

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

Comment 28

19 years ago
removing nsbeta3 nomination.
Keywords: nsbeta3

Comment 29

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

Comment 30

19 years ago
'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.

Updated

19 years ago
Whiteboard: future

Comment 31

18 years ago
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

Comment 32

18 years ago
reasigning to mstoltz. I'm not clear on what exactly we all want here.
Assignee: jband → mstoltz
Component: XPConnect → Security: CAPS

Comment 33

18 years ago
QA Contact -> ckritzer@netscape.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: 18 years ago
Resolution: --- → DUPLICATE

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 35

18 years ago
Verified dup.
You need to log in before you can comment on or make changes to this bug.