On Wed, 3 Jan 2001, Mitchell Stoltz wrote:
> 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.
ok. storytime, children :)
we assume that the underlying JS implementation will be secure wrt anything
provided as part of JS.
*all* of this security model is based on the existing 'doze version, which
interacts directly with IE's JS implementation (the same/equivalent way the
existing Linux version does).
Sash inherently is dangerous -- you're exposing the kind of functionality
"real" programs have to JS, stuff like writing to disk, talking to the network,
anything at all (since you can write a Sash extension library to do anything
you want). We do digital signature gobbledygook on any new native code we
install and basically hope it's not evil, since that's the best we can do. In
most cases, users aren't going around installing lots of untrusted extension
libraries from unknown sources. And the installer makes it clear this is a very
bad idea ("This extension you are about to install has no signature. It was
probably written by Atilla the Hun himself. It will steal your credit cards and
eat your children, most likely. Do you really want to do this? y/n").
But once we're actually running untrusted JS code, we're fine. Every installed
weblication (a web-enabled application written in JS; no i didn't make up that
term) has right wrt every installed extension. A weblication must state what
extensions it needs and what rights it requests at install time. The end-user
can at any time modify the rights he's granted a given weblication.
When a weblication actually runs, every call into an extension library is
checked against the rights that particular call requires. Correctly doing this
is the responsibility of the extension author (again, untrusted native code is
dangerous, can't change that). But we *can* do cute things like turn off all
the security permissions a weblication has been granted, and run it any
how. Then the runtime will pop up an evil-looking dialogue anytime the
untrusted weblication JS tries to do anything ("Hey! This weblication just
tried to do XXX, which requires permission YYY that you haven't granted
it! What do you say we just kill off this nasty little
weblication? continue/kill").
This makes perfect sense in the context of the Windows implementation, and of
the current Linux implementation, which relies on generated direct JS wrapper
code (we insert a new namespace "Sash." into JS, and handle all the JS
marshalling ourselves, with the aid of our PERL glue code generator). JS calls
come in, and we check them against the Sash security model.
Now I'm trying to move us to using XPConnect -- Sash extensions will be
directly exposed to JS. as far as i'm concerned, we can stick with the same
model for Sash privileges -- we'll still handle it on a function-by-function
basis (which is fine for Sash purposes, since Sash extensions don't give the
JS coder objects to deal with, only functions to call, a little bit
VB-like). The underlying COM objects will just check each call against the Sash
SecurityManager, exactly as they do now. Conceivably we could go to using a
security model more integrated with Mozilla's security model (basically by
inserting a lot of new privileges, and probably doing our own implementation of
the security manager). But i'm not convinced of the necessity.
> 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.
We need to make sure that untrusted weblication JS doesn't do anything evil
with XPConnect. Right now, if you try to turn on UniversalXPConnect from JS,
you get a (mozilla-proided) message box saying "This code has requested
UniversalXPConnect. Allow it to continue? y/n".
What Brendan told me will allow me to enable that from the C++ side (which
amounts to the controlling Sash runtime, trusted code written by yours truly).
Which means i can enable UniversalXPConnect, glue together the Sash namespace
(in JS), and turn off UniversalXPConnect. I need to make sure that calls to the
XPCOM objects i've exposed while UniversalXPConnect was on will still work with
it off. Basically, the untrusted JS should have access to *only* those objects
i've given it. I'm not sure if this will be the case (since i'm still fighting
some intermediate xpti hurdles to get my type info into mozilla; see the
running discussions with jband on n.p.m.xpcom).
For the time being it's fine if the alert box pops up if the untrusted JS tries
to turn on UniversalXPConnect itself. I'm willing to consider that a property
of the underlying browser-JS-environment-whatever security model. When all this
gets reported to Sean Martin (the senior engineer) he may feel differently, in
which case i'll take a second look at implementing the JS security manager
stuff for ourselves.
...
I'm not totally clear what you mean by "the calling code is running with the
system principle". from "i.e. it's a JS component" i take it you mean "we're
using JS to implement XPCOM components". That's not a problem for us -- that's
just not what we're doing. The goal is to make sure that the untrusted JS never
gets in a position where it can start to do that, since then obviously it can
start doing evil arbitrary things.
...
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)?
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)?
or am i still missing something?
ari
