David Hyatt wrote:
>
> 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.
