Changes between Version 12 and Version 13 of Security

Timestamp:

2007-12-17T19:27:45Z (17 years ago)

Author:

zooko

Comment:

--

Security

@@ -8 +8 @@
 
 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.
+   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.
+   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.
+   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 set permissions on your home directory or on the .tahoe directory so that others could not read the contents of files within it.  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
+ * 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.
+   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 to a third party, which means that third party gets access to the file.
 
-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.
+   If there is !JavaScript in the file, then it could deliberately leak the capability to the file out to some remote listener.
 
-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.
+   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 any !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.
+This will eventually be a summary of the general properties of the Tahoe secure decentralized filesystem.
 
 For technical details, there is [source:docs/architecture.txt the architecture document].