Is the security model XBL uses wrong?
Stuart Ballard
model that XBL is using. However, from discussions on the XBL newsgroup
and some brief experimentation, the rule appears to be that any content
built by XBL inherits its security principal directly from the document
_into which the anonymous content is being added_, regardless of the
security principal associated with the XBL document itself. If this is
wrong, please let me know and then disregard this entire email as the
rantings of a moron.
I claim that this model is the Wrong Thing, and also potentially harmful
in many ways.
Firstly and most obviously, this behavior prevents some potentially
useful applications of XBL. The example that led me to this realization
is an attempt to use XBL to bind a JavaScript action onto the html
<link> element in order to add that link to a toolbar (yes, the infamous
bug 2800). While it is possible to bind to <link> with XBL, the code you
write has no permission to access the toolbar, because it only runs with
the permissions of remote HTML. This, of course, is a pain. Another
possible blue-sky application of XBL that is ruled out by this security
model is the idea of implementing *all* of HTML using XBL - for example,
a constructor on the <title> element would set the title of the window
to "Mozilla - " plus the content of the title. Doing this with the
current security model would mean exposing the raw window-title-setting
function to remote HTML, which would mean that such HTML could remove
the "Mozilla - " string. I honestly believe that every html-specific tag
could be implemented by a combination of CSS and XBL, but only if the
security model is changed.
There is a more subtle issue, however. This model also potentially
*introduces* security holes. For example, currently a skin has to be
trusted, because it can provide XBL that binds into chrome:// documents
that are unrestricted. If XBL inherited its security principal from the
XBL document instead, the skin could be untrusted and javascript in
bindings provided by that skin would have no power to do harm.
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?
Thanks,
Stuart.
Ben Bucksch
>This model also potentially
>*introduces* security holes. For example, currently a skin has to be
>trusted, because it can provide XBL that binds into chrome:// documents
>that are unrestricted.
>
That would indeed be a problem, because skins are assumed to be
untrusted. E.g. the skin install dialog is different from the XPI dialog
in that the former doesn't warn about risks.
David Hyatt
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
> (hy...@netscape.com)
>
David Hyatt
> 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?
>
Neil
>javascript in bindings provided by that skin
>
You've been able to bind javascript in a skin? According to Dave Hyatt,
and I quote:
>Script is not allowed from "skin" XBL.
>
Neil
principal. I am guessing he wants to place a binding in
resource:/res/html.css and get privileges on the bound XBL. Is that
still a security hole? (probably:-)
Alex Fritze
> 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.
Wouldn't it be possible to add something like the
nsISecurityCheckedComponent-model to XBL?
E.g. an attribute 'useXBLDocPrincipal' on each method/property that, when
set, applies the XBL doc's principal for those methods.
In that way XBL would be much less restrictive but still just as secure as a
compiled code.
Alex
Stuart Ballard
Oh, I didn't know that.
However, my proposal would make it actually possible to include script
in a skin URL - it would just have restricted privileges, because a skin
url would be untrusted...
Stuart.
Stuart Ballard
>
> 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.
Stuart Ballard
Yes, that's exactly what I want - you expressed it much more succinctly
than I did.
Either that, or used the XBL document's principal but forbid access to
trusted XBL from untrusted CSS (much as trusted .js files cannot be
invoked <script src=""> in untrusted html).
Thanks for the clearer explanation :)
Stuart.
Stuart Ballard
>
> (Consider the XBL-form bindings too - there's
> no reason for them not to be privileged, if necessary).
I just realized that it probably *is* necessary for XBL form bindings to
be privileged: <input type="file"> requires access to privileged
functions to put up a filepicker dialog and also raw filesystem access
to read the resulting file for upload. How do you propose to do *that*
with only the privileges of remote HTML?
Stuart.
David Hyatt
based off of the principal of the stylesheet that attaches the binding.
Do I have that right? I'll have to re-examine the XBL exploits that
were found before I did all the tightening up on the model.
By the way, there is a long-standing bug about this problem. 59701. We
ran into this just as you have, since we've been wanting to build drag
and drop behavior into the embedding world using XBL (since we have all
the behavior over in XUL JS right now).
One exploit that immediately comes to mind is that someone could load a
chrome URL stylesheet from a remote Web page and then use the CSS object
model to add in new rules that point to remote XBL bindings.
So now that I think about it, you can't blindly use the CSS file's
principal. Maybe a model where you use the *least* privileged of the
CSS principal and the XBL document's principal? That way trusted CSS
pointing to untrusted XBL would result in untrusted XBL, but trusted CSS
pointing to trusted XBL would result in trusted XBL, even when bound to
an untrusted document. (Whew!)
dave
(hy...@netscape.com)
Stuart Ballard
>
> Sounds like you're proposing that the principal that XBL gets should be
> based off of the principal of the stylesheet that attaches the binding.
> Do I have that right? I'll have to re-examine the XBL exploits that
> were found before I did all the tightening up on the model.
Yes. (Private email from Neil pointed out the reason why this is
preferable to my other solution, which was to use the XBL document's
principal but simply refuse access to trusted XBL from untrusted CSS:
skin XBL needs to be able to use trusted chrome widgets).
> By the way, there is a long-standing bug about this problem. 59701.
I saw that bug too, but it didn't seem to be getting too much
attention...
> One exploit that immediately comes to mind is that someone could load a
> chrome URL stylesheet from a remote Web page and then use the CSS object
> model to add in new rules that point to remote XBL bindings.
Does the CSSOM actually let you add rules to a specific stylesheet (as
opposed to just adding rules in general)?
I think style rules added through the CSSOM should get their security
principal from the script that adds them, regardless of which stylesheet
they're added to. Of course, that's easier said than done, I expect...
but I'm really concerned more about Doing The Right Thing long-term than
with the short-term situation (much as a quick fix to this would be
nice!).
Giving rules added through CSSOM the security principal of the
stylesheet they're added to seems bad anyway... it basically precludes
using the security principal of the CSS for anything at all, because
it's so easily subverted.
I suppose another solution would be to forbid documents to link to CSS
files more trusted than they are: then the only way this could happen
would be when Mozilla itself does the linkage - specifically, html.css.
> So now that I think about it, you can't blindly use the CSS file's
> principal. Maybe a model where you use the *least* privileged of the
> CSS principal and the XBL document's principal? That way trusted CSS
> pointing to untrusted XBL would result in untrusted XBL, but trusted CSS
> pointing to trusted XBL would result in trusted XBL, even when bound to
> an untrusted document. (Whew!)
Are security principals strictly ordered? I always assumed that there
was only a partial ordering (ie, one principal might be able to do X and
not Y, while another can do Y and not X).
If there isn't a strict ordering, it should still be theoretically
possible (but probably harder) to construct a new principal that only
had permissions to do things that *both* principals could do.
Stuart.
Stuart Ballard
>
> So now that I think about it, you can't blindly use the CSS file's
> principal. Maybe a model where you use the *least* privileged of the
> CSS principal and the XBL document's principal? That way trusted CSS
> pointing to untrusted XBL would result in untrusted XBL, but trusted CSS
> pointing to trusted XBL would result in trusted XBL, even when bound to
> an untrusted document. (Whew!)
Actually, this wouldn't work either, if the CSSOM can be exploited as
you describe: that way all they have to do is add a binding to your
chrome://foo/usefulFileUtilities.xbl (from the exploit in your first
response) and they have local disk access.
Seems like the only solutions to this one are either:
1) Forbid use of the CSSOM on stylesheets more privileged than you are.
2) Give rules added to stylesheets by CSSOM the security principal of
the script adding them.
3) Forbid linkage to CSS files more privileged than yourself, except as
done implicitly by mozilla (to html.css for example).
I think that the first of these might actually be the simplest...
Stuart.
David Hyatt
current installed skin.
dave
Neil
>Seems like the only solutions to this one are either:
>
>1) Forbid use of the CSSOM on stylesheets more privileged than you are.
>
Does this not currently apply? Or can a remote web page manipulate
html.css? Not that it should need to, because it can supply more
specific (although less privileged) stylesheets.
Stuart Ballard
>
> The obvious drawback of (3) below is that remote XUL couldn't use the
> current installed skin.
> > 1) Forbid use of the CSSOM on stylesheets more privileged than you are.
> > 2) Give rules added to stylesheets by CSSOM the security principal of
> > the script adding them.
> > 3) Forbid linkage to CSS files more privileged than yourself, except as
> > done implicitly by mozilla (to html.css for example).
I'm definitely thinking that #1 is the way to go. Considering that it's
not possible to access the DOM of pages that aren't from the same *host*
as you (which is far more restrictive than just "are more priviliged
than you")... I can't think of any reason why pages should be allowed to
access or modify privileged stylesheets.
Given this, there's *still* a potential exploit if an attacker knows
that a certain chrome CSS file will bind a trusted file-access binding
to a certain element - he just has to apply that CSS file to a remote
XUL document of his choice.
I think the only secure way to do this is to somehow know whether the
CSS file was associated to the document implicitly by mozilla or by the
page author. Bindings in html.css are only secure because of the
combination of *three* factors:
1) html.css is trusted
2) The XBL file that it binds to is trusted
3) The association of html.css to the untrusted html file is done by a
trusted entity - ie mozilla.
(#2 here is actually unnecessary given #1 and #3, because it's okay to
"trust" the css file not to attach untrusted XBL so long as we know that
attackers can't abuse that css file. Also note that the "trusted entity"
in #3 might not have to be mozilla - it could be by manipulation of the
CSSOM by a trusted script, for example, although we don't have to
support this feature right away...)
I don't know how html.css becomes associated with html files, so
somebody more knowledgeable than me will have to explain this one. Is it
done by getting Mozilla to modify the CSSOM as soon as the document
starts loading, or is there something that makes html.css link in before
the CSSOM is even created? Is there a useful way to distinguish this
"implicit" css file with other ones added by the page author? Are there
any other such "implicit" css files?
Stuart.
PS The more I think about this the more I understand why it's such a
complex issue. I originally thought that "my approach" was clearly and
obviously better; my eyes have been well and truly opened to how
complicated it really is...
Stuart Ballard
>
> 1) html.css is trusted
> 2) The XBL file that it binds to is trusted
> 3) The association of html.css to the untrusted html file is done by a
> trusted entity - ie mozilla.
There's one really nice feature to the above logic that makes me think
that it really is the right way to go (not that I haven't thought that
about at least 4 different approaches previously, though, so take this
with a grain of salt...).
Consider:
#2 is irrelevant given #1, because if we trust the CSS file, we can
trust it not to bind to untrusted XBL; that would be Bloody Stupid.
#1 is irrelevant given #3, because we can trust the trusted entity here
to not be Bloody Stupid also.
So what this logic boils down to is that we can trust bindings if the
person (principal) that _makes_the_association_ from the document to the
css file is trusted.
Now, in 99% of cases, this association comes from a <link> or a <style
src> or an <?xml-stylesheet?> in the document itself. So in *all* of
these cases, we've reduced the logic down to "The security principal of
the XBL and the CSS file is completely ignored, and the security
principal of the document is used". It reduces to the current model!
The *only* case where it doesn't reduce to the current model is when the
CSS file is attached implicitly by Mozilla, or (perhaps theoretically)
by some other trusted entity. This means, basically, html.css and very
little else :)
The cool thing about this solution is that it keeps the known-secure
model for 99.9% of cases, while also opening it up enough for every
single thing that I can imagine doing using XBL (they would *all*
involve using html.css). And it provides a rationale for doing so.
Thoughts?
Stuart.
David Hyatt
executing privileged code by bringing in a chrome stylesheet with chrome
bindings.
Maybe you could condense this and post it into the bug, so we don't
forget what was decided here.
dave
Stuart Ballard
>
> Maybe you could condense this and post it into the bug, so we don't
> forget what was decided here.
Done.
Next question - what would it take to actually implement this change in
security model? When might it happen? And is there anything that, as a
non-mozilla-guru, I can do to help?
From an outsider's perspective, I can think of the following
pre-requisites:
1) Add a parameter to whatever function/method adds a stylesheet to a
document which takes a security principal to associate with this
association. Modify all callers to pass that parameter (in particular,
making sure that normal <link>, <style src> and <?xml-stylesheet?> pass
the document's security principal, but that whatever adds html.css
passes a trusted principal).
2) Store the resulting principal somewhere (is there even a structure
associated with the linkage between a stylesheet and a document? If not,
where do we store this?)
3) Do whatever is necessary to use this principal for XBL added by that
stylesheet (does a binding even know what CSS file added it?)
4) Make sure that html.css and similar files are not accessible through
CSSOM.
Like I said, I'm not a mozilla, style system, XBL, or C++ guru (the
extent of my patching is a 13-line-deletion in nsStdURL) but I'm quite
willing to have a stab at this if it's within my skills and if you can
give me some pointers as to where to start. If not, I'll do anything
else I can to help.
Stuart.
Ian Hickson
>
> Does the CSSOM actually let you add rules to a specific stylesheet (as
> opposed to just adding rules in general)?
Yes.
--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
Ian Hickson
>
> be privileged: <input type="file"> requires access to privileged
> functions to put up a filepicker dialog and also raw filesystem access
> to read the resulting file for upload. How do you propose to do *that*
> with only the privileges of remote HTML?
<input type="file"> is very, very special and shouldn't really be
considered when talking about XBL. We are likely to make <input
type="file"> unskinable, unbindable, and have the methods on its binding
uncallable. Don't be surprised if, in fact, we just use C++ to do the file
control binding. ;-)
Stuart Ballard
>
> On Thu, 28 Jun 2001, Stuart Ballard wrote:
> >
> > Does the CSSOM actually let you add rules to a specific stylesheet (as
> > opposed to just adding rules in general)?
>
> Yes.
Does that include giving remote html documents access to modify (their
instance of) html.css?
Stuart.
Ian Hickson
If they can get hold of it, yes. The CSSOM (rightly) gives no way for
script to get a pointer to the UA or user stylesheets, though.
Stuart Ballard
>
> > Does that include giving remote html documents access to modify (their
> > instance of) html.css?
>
> If they can get hold of it, yes. The CSSOM (rightly) gives no way for
> script to get a pointer to the UA or user stylesheets, though.
How sure are you that they can't get hold of it? How secure would you
feel if you knew that there was a remote-write-access-to-your-local-disk
exploit that would be possible if they could get hold of a pointer to
html.css?
The reason I ask is that, based on other subthreads here, it looks like
we want to move to a model where XBL rules added through html.css are
trusted. This opens up an exploit if a remote document can modify its
instance of html.css, since any bindings it adds through html.css would
execute trusted. Based on your knowledge of CSSOM, would you feel
comfortable making this change without adding extra restrictions (eg
ensuring that they couldn't modify html.css even if they found it)?
Thanks,
Stuart.
Mitchell Stoltz
any local file?
-Mitch
Ian Hickson
> Ian Hickson wrote:
> >
> > > Does that include giving remote html documents access to modify (their
> > > instance of) html.css?
> >
> > If they can get hold of it, yes. The CSSOM (rightly) gives no way for
> > script to get a pointer to the UA or user stylesheets, though.
>
> How sure are you that they can't get hold of it?
Pretty sure.
> How secure would you feel if you knew that there was a
> remote-write-access-to-your-local-disk exploit that would be possible
> if they could get hold of a pointer to html.css?
It wouldn't be write access to the hard disk; but I wouldn't like it if
script could, on the fly, change my user stylesheet preferences, even on
a per-session basis.
> The reason I ask is that, based on other subthreads here, it looks like
> we want to move to a model where XBL rules added through html.css are
> trusted.
Ok... (We had better make sure none of the methods of those bindings do
anything dodgy, btw!)
> This opens up an exploit if a remote document can modify its instance
> of html.css, since any bindings it adds through html.css would execute
> trusted.
Sure. Thankfully, that can't be done. (Or if it can, it's a very serious
privacy bug.)
> Based on your knowledge of CSSOM, would you feel comfortable making
> this change without adding extra restrictions (eg ensuring that they
> couldn't modify html.css even if they found it)?
I don't see the point. We have a security model here ("you can't get
access to the stylesheet"), we should rely on it working. Using multi-tier
security models seems needlessly wasteful. (Also, how would you test it?)
It would be a serious privacy bug even if you could _read_ the UA or user
stylesheets through the CSSOM.
ObDisclaimer: I'm no security expert!
Stuart Ballard
>
> That would be bad. How could an attacker modify html.css any more than
> any local file?
I'm referring to modifying the in-memory instance of html.css associated
with a given document - in general, a document can modify its own
stylesheets through the CSSOM. My question to Hixie was whether this
included being able to get access to the copy of html.css which is
"implicitly" associated with all html documents - not whether they could
actually change the file on disk.
Stuart.
Stuart Ballard
>
> On Sat, 30 Jun 2001, Stuart Ballard wrote:
>
> > How secure would you feel if you knew that there was a
> > remote-write-access-to-your-local-disk exploit that would be possible
> > if they could get hold of a pointer to html.css?
>
> It wouldn't be write access to the hard disk; but I wouldn't like it if
> script could, on the fly, change my user stylesheet preferences, even on
> a per-session basis.
My question was in view of the potential change in security model below,
which would mean that it *would* change this from a "able to read my own
private stylesheet" into potential full trusted XPConnect access -
including local file write.
> > The reason I ask is that, based on other subthreads here, it looks like
> > we want to move to a model where XBL rules added through html.css are
> > trusted.
>
> Ok... (We had better make sure none of the methods of those bindings do
> anything dodgy, btw!)
Well, the bindings themselves would be code written by mozilla.org so we
can trust them as much as any other code[1]. The problem would occur if
a document could insert its *own* bindings here in which case we would
be in deep trouble.
> > This opens up an exploit if a remote document can modify its instance
> > of html.css, since any bindings it adds through html.css would execute
> > trusted.
>
> Sure. Thankfully, that can't be done. (Or if it can, it's a very serious
> privacy bug.)
Good.
> I don't see the point. We have a security model here ("you can't get
> access to the stylesheet"), we should rely on it working. Using multi-tier
> security models seems needlessly wasteful. (Also, how would you test it?)
Excellent - my previous question was really just another way of asking
"Do you consider this inability to get access to the stylesheet as a
security precaution, or just a coincidence?".
> It would be a serious privacy bug even if you could _read_ the UA or user
> stylesheets through the CSSOM.
Good! This is the answer I wanted to hear - that you already care about
this, even without the additional importance caused by the proposed
change.
Stuart.
[1] Hopefully there isn't *any* code in mozilla that's doing anything
dodgy! ;)
Ian Hickson
> > >
> > > The reason I ask is that, based on other subthreads here, it looks like
> > > we want to move to a model where XBL rules added through html.css are
> > > trusted.
> >
> > Ok... (We had better make sure none of the methods of those bindings do
> > anything dodgy, btw!)
>
> Well, the bindings themselves would be code written by mozilla.org so we
> can trust them as much as any other code[1].
The point is the bindings are exposed to script, so they musn't do
anything exploitable. Just like the 'window' object musn't have any
methods that shouldn't be called by untrusted script, etc.
Again, I'm not a security person, I could be talking nonsense...
> Good! This is the answer I wanted to hear - that you already care
> about this, even without the additional importance caused by the
> proposed change.
Totally. UA and user stylesheets must not be accessable by untrusted
script. It is very much an issue.
Axel Hecht
Thanx
Axel
Stuart Ballard
>
> At some time, a bug was supposed to be filed, could you post the number?
Eric Murphy
Mozilla via my in-progress XPCOM code.
Here is an example that explains it all:
1. http:// Web page that has CSS to a chrome URL like:
chrome://jabberxm/skin
I really don't care about calling bindings specifically via my own CSS.
2. jabberxm.css has the definitions of my bindings, and also uses chrome
URLs like:
chrome://jabberxm/content/roster.xml
3. roster.xml instantiates my JabberXM component (written in
JavaScript). It does this in the binding's constructor
4. roster.xml can work with the function in the JabberXM component, like
the tcp socket, JabberXMSax parser, in-memory RDF datasources, etc. I
may add disk access functions to the component in the future.
The purpose of this example is to display a user roster in web content,
with all the functionality happening in the component. If the person has
JabberXM installed in their browser, they can see their roster, if not,
then they won't see anything.
Hopefully something can be worked out before Mozilla 1.0 so that I can
do stuff like this... there are a lot of possibilities...
Eric
Stuart Ballard wrote:
> First off, I'd like to clarify that I don't know first-hand the security
> model that XBL is using. However, from discussions on the XBL newsgroup
> and some brief experimentation, the rule appears to be that any content
> built by XBL inherits its security principal directly from the document
> _into which the anonymous content is being added_, regardless of the
> security principal associated with the XBL document itself. If this is
> wrong, please let me know and then disregard this entire email as the
> rantings of a moron.
>
> I claim that this model is the Wrong Thing, and also potentially harmful
> in many ways.
>
> Firstly and most obviously, this behavior prevents some potentially
> useful applications of XBL. The example that led me to this realization
> is an attempt to use XBL to bind a JavaScript action onto the html
> <link> element in order to add that link to a toolbar (yes, the infamous
> bug 2800). While it is possible to bind to <link> with XBL, the code you
> write has no permission to access the toolbar, because it only runs with
> the permissions of remote HTML. This, of course, is a pain. Another
> possible blue-sky application of XBL that is ruled out by this security
> model is the idea of implementing *all* of HTML using XBL - for example,
> a constructor on the <title> element would set the title of the window
> to "Mozilla - " plus the content of the title. Doing this with the
> current security model would mean exposing the raw window-title-setting
> function to remote HTML, which would mean that such HTML could remove
> the "Mozilla - " string. I honestly believe that every html-specific tag
> could be implemented by a combination of CSS and XBL, but only if the
> security model is changed.
>
> There is a more subtle issue, however. This model also potentially
> *introduces* security holes. For example, currently a skin has to be
> trusted, because it can provide XBL that binds into chrome:// documents
> that are unrestricted. If XBL inherited its security principal from the
> XBL document instead, the skin could be untrusted and javascript in
> bindings provided by that skin would have no power to do harm.
>
> 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?
>
> Thanks,
> Stuart.
>
Ian Hickson
>
> The purpose of this example is to display a user roster in web content,
But this is a security (well, privacy really) hole. If any web page can do
this, then you end up with the possibility of a hostile page getting
access to the user roster (through the DOM).
Isn't the technical solution to this to require the page to be signed? I
don't know anything about that really. :-)