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])


Reply via email to