I should clarify that there may someday be plans to move away from a
simple on/off model to a model where privileges can be requested and
then granted to a Web page, but that wouldn't affect how XBL installs
its JS at all.
The security guys could better address questions about a
capabilities-based model, and it's really just a general JS code issue
that is independent of XBL.
dave
David Hyatt wrote:
> Stuart Ballard wrote:
>
>> First off, I'd like to clarify that I don't know first-hand the security
>> model that XBL is using.
>
>
>
> 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.
>
> 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.
>
>
>> Can anyone comment on why the current behavior was chosen for XBL,
>> whether there are any plans to change it, and whether there are any
>> holes in my arguments?
>>
>
>
> 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.
>
> Perhaps you'll understand the model better if any time you think of a
> binding like the one above, you imagine how it would work if you'd just
> included the methods in a script that was included via a <script> element.
>
> So instead of using XBL to bind your file utility functions to some
> random element in an HTML doc, you'd use a script tag instead to bring
> in file utility functions.
>
> <script src="chrome://blah/content/fileUtils.js">
>
> and fileUtils.js has a function
>
> function removeDir()
> {
> }
>
> 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.
>
> Hope this clears things up,
> dave
> ([EMAIL PROTECTED])
>
