Mitchell Stoltz wrote:
>
> >
> >
> > So there's two issues here.
> >
> > 1) Some trusted JS turns on UniversalXPConnect, exposes some underlying safe
> > stuff to JS, and turns UniversalXPConnect off. Will subsequent untrusted JS be
> > allowed to do evil XPConnect stuff (it shouldn't be)?
>
> No, it won't be able to access XPConnect.
>
> >
> > 2) Some trusted JS turns on UniversalXPConnect, exposes some underlying safe
> > stuff to JS, and turns UniversalXPConnect off. Will subsequent untrusted JS
> > still be ablee to access the XPCOM objects previously exposed (it should be)?
>
> I don't think the untrusted JS will be able to access the XPCOM objects
> previously exposed. Every access to an XPCOM object through JS generates
> a security check, which will fail if UniversalXPConnect is not enabled.
> The way around this is to mark your "underlying safe" XPCOM objects as
> exempt from the security check. We have not yet settled on the best way
> to do this, but an interim solution exists. Have your safe XPCOM objects
> implement the nsISecurityCheckedComponent interface.
Ari is working in the context of his own embedding. I suggested
elsewhere that the thing to do is to not rely on the
mozilla-the-browser security system at all for xpconnect, but to
install an nsIXPCSecurityManager implementation that embodies the
security policy appropriate for this embedding.
John.
> -Mitch
>
> >
> >
> >
> > or am i still missing something?
> >
> >
> > ari
> >
> >
> >
> >
> >
> >
>
> --
> ---------------------
> Mitchell Stoltz
> Netscape Client Security & Privacy
> (650)937-2437
> [EMAIL PROTECTED]
> PGP Fingerprint:
> 3164 B077 479F 9C5B 17B8
> 4A2B 6E22 CD7C 35A2 95DD
> ---------------------
