Ian Hickson wrote:
>
> 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! ;)
