Security Considerations

This page exists so that there is a single place to go to learn about the general security properties of Tahoe, as well as about any current known issues that might have security consequences.

Current Known Security Issues in Tahoe

as of December 17, 2007

• privilege escalation for directory servers

In the v0.6.1 release of Tahoe, it was intended and documented that you could grant read authority, read/write authority, or no authority to any person. We overlooked the fact that the limitation on write authority does not apply to people who control the directory server on which your encrypted directory resides. If you grant read-authority to such a person, they automatically get read-write authority.

The next version of Tahoe, v0.7.0, which will be released soon, fixes this issue by using more powerful cryptography. In Tahoe v0.7.0 you can grant read authority, read/write authority, or no authority to any person and they are unable to get more authority than you've granted them, even if they control some of the servers on which your encrypted files and directories reside.

• temporary exposure to local attacker

In the v0.6.1 release of Tahoe, there was a short window of opportunity in which a local user on your system could read secrets out of the ~/.tahoe directory after they were written into that directory but before their permissions were set to be not-world-readable. This would be prevented on unix-like systems if you turned off the 'x' permissions bit on your home directory or on the .tahoe directory. In the upcoming v0.7.0 release of Tahoe such secrets are kept in a subdirectory of the ~/.tahoe directory, named ~/.tahoe/private, which is set so that users other than its owner cannot read data from files within it.

• potential exposure of a file through embedded hyperlinks or JavaScript in that file

If there is a file stored on a Tahoe storage grid, and that file gets downloaded and displayed in a web browser, then JavaScript or hyperlinks within that file can leak the capability to that file. Anyone who receives the leaked capability gets access to the file.

• JavaScript: if there is JavaScript in the file, then it could deliberately leak the capability to the file out to some remote listener.
• hyperlinks: if there are hyperlinks in the file, and they get followed, then whichever server they point to receives the capability to the file. Note that IMG tags are typically followed automatically by web browsers, so being careful which hyperlinks you click on is not sufficient to prevent this from happening.

For future versions of Tahoe, we are considering ways to close off this leakage of authority while preserving ease of use -- the discussion of this issue is ticket #127.

For the present, a good work-around is that if you want to store and view a file on Tahoe and you want that file to remain private, then remove from that file any hyperlinks pointing to other people's servers and remove JavaScript unless you are sure that the JavaScript is not written to maliciously leak access.

General Security Properties of Tahoe

This is a summary of the general properties of the Tahoe secure decentralized filesystem.

For technical details, there is the architecture document.