David Hyatt wrote:
>
> The model is quite simple. The principal associated with an XBL
> document is completely ignored. Methods and properties (as well as
> event handlers) use the principal of the document that corresponds to
> the element that has the XBL binding attached to it.
Okay, this is what I had assumed.
> So a remote HTML document that binds to privileged chrome URLs will not
> be able to install privileged code onto its elements and then invoke
> that privileged code from within the HTML document.
Or, correspondingly: even XBL from a trusted source cannot perform
privileged operations if it binds to untrusted content.
> No, there are no plans to change it, because to do as you suggest would
> create a gaping security hole. Consider a binding in a chrome URL of
> the form:
>
> <binding id="usefulFileUtilities">
> <method name="removeDir">
> ... code that accesses our file services and that deletes
> directories...
> </method>
> </binding>
>
> If you allow this code to be privileged when invoked from an element in
> remote HTML, then presto, you've just given all Web pages the ability to
> manipulate the user's file system.
I don't see how that is a security hole. Or rather, I would consider
that in that case the security hole lies in the usefulFileUtilities
binding, not in the security model.
Consider the example I gave of the HTML "title" element. We obviously
don't want untrusted HTML to be able to set the raw window title,
because for security reasons we require that "Mozilla -" always appears
in the title. But if we were to use a trusted binding to the <title>
element, we could add the word "Mozilla" and *then* call the trusted
method.
[snip good example]
> Do you really expect to be able to do *that* from a Web page? We don't
> even allow chrome URLs to be loaded from <script> tags in docs that
> aren't also chrome. At least XBL lets you run the code in an
> unprivileged mode. That's more than you get trying to do it with a
> <script> solution.
Perhaps the difference in our opinions is because you are assuming the
binding will be attached by remote CSS, and I'm assuming it will be
added in (say) html.css. (Consider the XBL-form bindings too - there's
no reason for them not to be privileged, if necessary).
I should clarify, then, that I'm assuming that remote CSS would not be
able to attach to a chrome:// binding, and only trusted (eg chrome://)
CSS would be able to access these trusted bindings. Would that address
your concerns while still allowing the XBL code to run privileged?
Stuart.
