Ari,
How is your untrusted JS run, and how are you enforcing a sandbox
around it? If the calling code is running with the system principal (ie.
it's a JS component or a chrome document) then any code called from that
code, no matter its source, is also fully privileged. Just disabling
UniversalXPConnect is seless; the untrusted code can always re-enable
it. We're about to add a "sandbox eval" function which will evaluate
code in an untrusted sandbox; this isn't in the tree yet but should be
very soon. I'll send an example when it's ready. Also, look at
http://www.mozilla.org/projects/security/components/jssec.html for a
discussion of enabling capabilities.
-Mitch
Brendan Eich wrote:
> Ari Heitner wrote:
>
>> brendan,
>>
>> blizzard suggested i run this by you:
>>
>> i need to enable UniversalXPConnect to glue some magic objects
>> together before
>> i load untrusted JS. then i need to disable this (so that the
>> untrusted JS
>> doesn't do anything it's not allowed; it's in a very strict sandbox).
>> and i
>> need to do it all from an embedding application.
>>
>> i'm sure there's a straightforward way to do it. any point to
>> docs/example/code
>> to read would be appreciated.
>
>
> Enabling and disabling a capability requires using
> nsIScriptSecurityManager (caps/idl/nsIScriptSecurityManager.idl, which
> contains horrid tabs and InterCaps method names rather than interCaps
> -- mstoltz, I'm whining at you).
>
> XPCOM's service manager lets you get a service, so I think you're
> done. Cc'ing mstoltz and jband for their better-informed responses.
>
> /be
>
>
--
---------------------
Mitchell Stoltz
Netscape Client Security & Privacy
(650)937-2437
[EMAIL PROTECTED]
PGP Fingerprint:
3164 B077 479F 9C5B 17B8
4A2B 6E22 CD7C 35A2 95DD
---------------------
