[tahoe-dev] Tahoe presentation at cap-talk, plus sundry security notes

[zooko]

Folks:

Brian and I presented the basic access control architecture of Tahoe  
at the "capabilities discussion group" at HP Labs last Friday.  (See  
the cap-talk mailing list [1] for more information about that area of  
security research.)

Here are Brian's notes that he wrote after the presentation:

------- begin included Brian notes
captalk: presented tahoe webapi, got good feedback on security issues:

     * remove the navbar that lets you traverse up to parent  
directories, rely upon browser 'Back' button instead
     * most users will share by copying URL field, need to make that  
a read-only form
           o could use JS to replace the URL field with a read-only  
form after loading the read-write form
     * when displaying individual files, we need to protect against  
referrer-headers and embedded JS
           o use fragment+JS to cleanse the URL, or bounce through a  
nonce
     * overall they were excited about it
------- end included Brian notes

Another security issue that we discussed is that access to the  
"upload" feature of a node is not guarded by a secret, currently.  In  
theory, this could mean that it is vulnerable to an XSRF attack, such  
as the ones that we fixed in the v0.5.1 release, however the value of  
such an attack to the attacker would be somewhat limited by the fact  
that the only things that he could cause us to upload would be  
literals that came bundled with the XSRF form itself.  In any case,  
we intend to change this to make the upload feature be a capability  
which is accessible only to the holder of a specific secret, because  
that way we can do accounting for which nodes are responsible for how  
much storage usage.  As a side-effect, this will fix the XSRF attack.

Similarly for deleting links from the public vdrive -- to do so does  
not currently require a secret, but on the other hand people can  
always delete things from the public vdrive themselves, without  
tricking someone else's Tahoe node into doing it for them.

After the cap-talk meeting, Brian and I agreed -- I thought -- not to  
bother making the URL field read-only, and instead to document the  
fact that sharing a URL will (by default) share write access to your  
directory as well as read access..  Apparently Brian remains  
interested in a JavaScript hack to read-only-ify URLs after loading  
them.

Regards,

Zooko

[1] http://www.eros-os.org/mailman/listinfo/cap-talk