On Wed, Aug 18, 2010 at 2:50 AM, Tim Wintle <tim.win...@teamrubber.com>wrote:
> On Tue, 2010-08-17 at 11:35 -0700, ๏̯͡๏ Jasvir Nagra wrote: > > > > For code in the caja subset of javascript/html, the cajoled gadget can > > safely be on the same origin as the container. The security policy > > does not rely on origin but rather the choice and implementation of > > APIs that the container exposes to the gadget. > > Is there an actual proof of the behaviour of Valija? > No - there isn't a proof - at least not in the traditional sense. We ran a security review on "old caja" a year ago where we invited a team of external security reviewers lead by David Wagner to review and attack the system. The results of the review are available here<http://google-caja.googlecode.com/files/Caja_External_Security_Review_v2.pdf>. The review suggested the design was sound, however, recommended changes in the implementation architecture. The split between Valija (a translation from legacy code) and Cajita (a smaller, more reviewable secure TCB) that you mention was the result of these recommendations. We're close to releasing a new version caja that supports a larger subset of javascript (in essence supports ES5-strict by translation on existing browsers). This will support for libraries like jQuery without requiring a large number of changes in the library. At that point, we will run another security review of the new design. > > My understanding was that Caja handled different vulnerabilities - > adding extra security to iframes, and aiming for the same security that > iframes add, but not quite there yet. > I would not characterize it as such. Caja provides a superset of the guarantees that iframes provide. The important distinction is security that iframes provide under the control of the browser manufacturer not the container. Different browsers make different choices about what code in an iframe should be able to do - for example, with cookies, with getComputedStyle, with parent frame redirection. These choices may or may not align well with what a particular shindig deployment wants to provide to third party gadgets. If a containers security policy happens not to align well with the security policy browsers enforce on iframes or if containers need to be able to modify their security policy over time (because threats change or vulnerabilities in a browser), then the container has two choices - either to bake its security policy into the third party code it runs, or to scan for problematic gadgets the way anti-virus programs do. I may well have missed some milestone with caja over the past year or so > though. > > > Tim > >
