On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote: > , and this sandboxed eval, with the getters and setters of ES4, > developers can create safe sandboxes with host object wrappers with > fine grained access control to enable cross site scripts to be > loaded and executed with controlled limited ability to interact > with environments. I think if we had these capabilities, the most > gaping hole in browser security could be effectively dealt with.
There are lots of exploits. Gaping holes that careful JS coders can close, with the right tools, should be closed -- first the right tools are needed as you note. But defense in depth plus fallible human nature mean that no one is ever careful enough. The crackers find really subtle holes. Security is never "done". So while I am in favor of something like Doug's proposal, I'm not so confident as you are. > One thing could make this a little smoother would be a constructor > for a global object, with it's own set of global values, Object, > Array, etc. for the sandboxed code to mutilate. Nice, but I don't > think necessary. This is exactly the path we went down. Obviously my a + b * c == 42 example is a useless toy. Real uses of eval like this will want to evaluate complex object graphs, possibly even containing functions. It's a sandbox, right? Should be safe. Not so fast: * Information can flow out of the sandbox as well as into it from the evaluated string. What result types should be allowed? If dynamic objects, see below. * From GreaseMonkey experience, the trusted caller of evaluate often wants to add new API functions and objects to the sandbox. This cannot be done safely in ES3. Among other problems are the mutable prototypes, and Function.prototype.call/.apply which fixtures do address. * This kind of sandbox is a leaky reference monitor in general. There is no mandatory access control specified for all control flows. Implicit flows[*] are unmonitored. We have experience going back to Netscape 4 (and earlier) that such a system is "advisory" -- people may use it, or not; they may use it in one place and not in another; they may use it but it's easy to leak information across the sandbox object reference, and out from the return value. Some proposals have insisted on primitive types only as the result. That's insufficient, and judging from real web apps and add-ons such as GM, crippling. > Perhaps, I am missing something, and I don't know for sure how to > capitalize the s in security, but this seems a way more valuable > asset to security than constraints provided by fixtures and > intrinsics. Please don't set up a false dilemma. As noted above, without fixtures and other mutability controls missing from ES3, you can't safely inject added APIs into the sandbox. You can't even trust the sandbox object after the evaluate, in the sense that even getting a property from an object in it might trigger a getter, with unexpected results. The trust label for the getter's code should be other than the trust label of evaluate's caller, of course, and perhaps there is a reference monitor comparing those labels somehow. But now the mission creep has turned into a whole new, extremely "researchy", mission, until ES4 specifies mandatory access control (MAC) and even non-interference: secure information flow: public and secret inputs to a program only mix in secret outputs, never in public outputs. Security is never simple, and from our experience in Mozilla, it actually hurts to be simplistic about things like an eval sandbox. Nevertheless! I'm in favor of something like Doug's proposal, but it needs a vigilant detailing and critical thinking about the issues you raise, and others. These issues are not peripheral or minor: * populating the sandbox with standard objects, * populating it with custom objects, * explicit result type restrictions, * sandbox side effect hazards, including code (getters on objects in the sandbox, etc.) * (from the last point) mutation controls in general -- new in ES4, not in ES3 * real end-to-end MAC for implicit flows, information security. /be [*] http://www.informatik.uni-trier.de/~ley/db/journals/cacm/ cacm19.html (ACM members: http://portal.acm.org/citation.cfm? id=360056 -- anyone know of a free version?) _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
