Re: [tahoe-dev] How to use Caja to solve the same-origin policy hazard (hosting both webapps and untrusted content in Tahoe)
On Jul 30, 2011, at 4:50, Greg Troxel wrote: In your worldview, are there multiple WUIs? I can see the desire to use tahoe as a backing store for a web server, but until there are redundant WUIs and the client can select among them - I don't see the point compared to just running apache with the content in tahoe. And when the client can fail over among them, isn't that almost like having the client be a tahoe node? My proposal says nothing about the number of gateways, and I was largely assuming the default Tahoe model of every user running their own gateway (everybody's localhost:whatever). This is not *just* to support the unhosted-web-app scenario, but also to protect a file-upload-and-download user working through the WUI (which is one of my current two personal use cases for Tahoe). -- Kevin Reid http://switchb.org/kpreid/ ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] How to use Caja to solve the same-origin policy hazard (hosting both webapps and untrusted content in Tahoe)
Dear Kevin: Your letter fills me with internal conflict! On the one hand I'm delighted because what you propose is not only the best way to further protect against the dangers of looking at files stored inTahoe-LAFS through a web browser, but it also opens up the possibility of even better decentralized web apps. That's because caja supports the safe composition of mutually distrusting Javascript programs. What could people do with that? I'm not sure, but I have a feeling it could be fantastic. On the other hand: Java. I hate Java, and I hate the JVM. And even if I could hold my nose and overcome my personal antipathy, the fact that caja requires Java to run the cajoler imposes a huge difficulty in terms of packaging and deployment for Tahoe-LAFS. I haven't thought through all the details yet, but would it would mean the end of the quickstart procedure [1]? With the quickstart procedure, users on any operating system can build Tahoe-LAFS themselves from source. (This currently works most of the time for most users.) If we can no longer support that method of deployment, that would herald the beginning of a new era in which users (who aren't skilled developers) can't really use the source code themselves but need to rely on someone else to provide them with a prebuilt package. That would be regrettable, but I guess it would be worth it, since it is probably the best way to further improve the WUI's safety and the only way to allow safe composition of mutually distrusting Javascript. Regards, Zooko [1] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] How to use Caja to solve the same-origin policy hazard (hosting both webapps and untrusted content in Tahoe)
On 7/29/11 5:39 PM, Kevin Reid wrote: Given the two origins, the only way you are in danger is if you have two “raw” (from origin #2) documents open in your browser at once The tab's history is also an angle of attack, so I think another danger is to open two different documents in sequence in the same tab (perhaps doc1 has a link to doc2 and the user follows it), and the vulnerability is that the code in doc2 could learn the filecap of doc1. This scheme also has a nice division to it: Origin #1 serves only content generated by Tahoe-or-Caja; Origin #2 serves only arbitrary uploaded content. I like it. I'm not willing to add Java to Tahoe's dependency set, but I'm happy to say that you only get these protections if you're running an ES5-capable browser (and using the JS-only cajoler), and older browsers remain vulnerable to cross-document attacks (just as they are now unless you use NoScript/etc against your WUI). I'm not sure that rewritten by Caja is a sufficient description of what needs to be done, since cajoling merely adds confinement, without necessarily establishing the bridges that let the now-confined code do something useful. As you pointed out, what this actually needs is a simple Caja+(single-page-viewer) function, in which confined code that only uses a well-known subset of the usual page authority will continue to work normally. Code which reaches outside that set should fail. What exactly is that subset? What parts of the usual page authority do we want to deny? Certainly the ability to script other windows (normally granted by window.opener or a guessable window name when the target has the same origin). Also the ability to read the history or current URL out of other windows. Those are the two main attack vectors we've examined so far. We can probably leave the app full control over the window's DOM, and XHR, as long as the membrane keeps it from leveraging that into unconfined eval. I've always thought of Caja itself as a tool to build sandboxes with specific powers, but of course the Caja project must also have other tools to define some useful types of sandboxes. I don't know where those other tools are or how you express that control. [Disclosure: I am currently being paid to work on Caja.] Being paid to work on Caja means you probably actually know how to pull this off :). It's too easy for the rest of us to imagine that run all pages through Caja is some sort of magic security dust that can be sprinkled onto HTML to make it all safe, and you're just the sort of person to help us clarify what'd we'd actually need. So I think it's a good thing :). cheers, -Brian ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
