Catchall proposal

[Brendan Eich]

On May 6, 2009, at 10:53 AM, Mark S. Miller wrote:

> On Wed, May 6, 2009 at 10:11 AM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> Let's cut to the chase if we can. I don't buy the SES first, since  
>> it's not
>> clear SES is usable but Web Sandbox and others like it are already  
>> in use.
>
> For the record, other like it are indeed already in use (FBJS[2?] on
> Facebook, Valija on YAP). AFAICT, WebSandbox itself isn't yet. This
> isn't quite fair as we intend to borrow many of their good ideas.
>
> We've been using Cajita enough internally at the Caja project, and it
> is similar enough in flavor to E, that I am confident it is usable.

I didn't mean to pick on Caja. It does seem the Web Sandbox approach,  
FBJS2, etc. is more likely to be usable, all else equal.


> Yes, these scale of these is infinitesimal compared to historic ES
> use. Based on the record to date, it is clear that full ES has *not*
> been usable as a secure language.

The question of a programming language being secure is interesting,  
but it may miss the target given security properties being end-to-end  
system properties. A language with better properties than ES may be  
necessary, but not sufficient, so stripping ES down to something  
secure may not improve practical security, and could impair usability  
by comparison to alternative approaches.

We need better security by default in JS+HTML+DOM+CSS+SVG+XSLT+... --  
we can't throw the system out, but we can evolve it with some  
compatibility breaks.

This is a big topic, I'll save it for another day.


> And in any case, you started this subthread by asking "What do other
> secure subsetters say?" SES is a subset. WebSandbox, Valija, and FBJS2
> ideally aren't -- they are a virtualization/emulation of the "whole"
> language (given a suitable definition of "whole" -- Valija will do
> ES5-strict).

Yes, sorry for using subsetters when I meant to summon sandboxers.  
Catchalls are for various use-case, mainly the virtualization one used  
for sandboxing and emulating.


> These whole language emulations are not "secure", they
> are only sandboxed. Since the language being emulated is not secure, a
> faithful emulation of that language must preserve its insecurities.

Or solve them otherwise.

You assume people have to write in what you call a secure subset or  
live with insecurities in a sandbox that confines threats. I don't  
think that's the only way to solve the whole-system problem, i.e, to  
enforce security properties like integrity and secrecy against mixed  
trust threats.

Especially since, as noted above, security properties need to be  
enforced in the system, not just the language. Combine this conern  
with usability issues in the subsets (starting with the need to  
relearn and rewrite), and the suspicion grows that an end-to-end and  
system-wide approach might yield both better security property  
enforcement *and* greater usability.

But again this is a bigger topic than catchalls and I will shut up for  
now.


> Both the Cajita-like and Valija-like levels are important. For the
> Cajita-like level, the remaining pressing issue beyond ES5 is the
> whitelisting issue David-Sarah raises.

That is gonig to be a struggle. Whitelisting in the VM might be useful  
but there are many ways to do it, with different performance vs.  
expressiveness tradeoffs. Separate thread? Restart the one DSH posted  
in if need be.


> For the Valija-like level, I
> think the most important enabler would be some kind of hermetic eval
> or spawn primitive for making a new global context (global object and
> set of primordials) whose connection to the world outside itself is
> under control of its spawner.

Mozilla has had such a thing (Components.utils.evalInSandbox) for a  
while and it's indispensable. So yeah, let's standardize a solution  
everyone can use.


> With such a primitive, we would no
> longer need to emulate inheritance and mutable globals per sandbox.

Who "we"? People writing or adapting web JS might. There's no free  
lunch but there might be a lower rewrite tax. Or no tax in the JS  
language level, more in policy -- site-specific content restrictions  
and policy declarations.


> Catchalls are likely to be a relevant enabler at both the Cajita-like
> and Valija-like levels. We can discuss both simultaneously if you
> like, but I suggest we would have a clearer discussion if we take
> these mostly in bottom up order.

Your taxonomy is not shared by everyone, and it contains assumptions  
I've questioned. I'd rather start from real-world use-cases wherever  
they may be.

/be