Yeah, that makes a lot of sense to me. It also prevents remote XUL from
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 wrote:
> Stuart Ballard wrote:
>
>>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.
>
