[Python-Dev] doc for new restricted execution design for Python

[Mark Hammond]

Bob writes:

> I don't know how JavaScript is doing it yet.  The critical thing
> for me for this month was trying to come up with a security model.

I don't fully understand how JS does it either, certainly not in any detail.
I know that it uses the concept of a "principal" (the IDL file can be seen
at http://lxr.mozilla.org/seamonkey/source/caps/idl/nsIPrincipal.idl) and I
think that the absence of any principals == "trusted code".  I believe the
principals are obtained either from the JS stack, or from the "event source"
and a few other obscure exceptions.  There is also lots of C code littered
with explicit "is this code trusted" calls that makes implicit and explicit
javascript assumptions - not particularly deep assumptions, but they exist.

Cross-language calls will also need consideration.  JS will be able to
implicitly or explicitly call Python functions, which again will implicitly
or explicitly call JS functions.  Some of those frames will always be
unrestricted (ie, they are "components" - often written in C++, they can do
*anything*), but some will not.  We have managed to punt on that given that
Python is currently always unrestricted.

In the early stages though, Mozilla is happy to have Python enabled only for
trusted sources - that means it is limited to Mozilla extensions, or even a
completely new app using the Mozilla framework.  From a practical viewpoint,
that helps "mozilla the platform" more than it helps "firebox the browser"
etc.  This sandboxing would help the browser, which is great!

I'm confident that when the time comes we will get the ear of Brendan Eich
to help steer us forward.

Cheers,

Mark.