[tahoe-dev] protecting caps

Greg Troxel gdt at ir.bbn.com
Mon Aug 1 23:20:56 UTC 2011

Joseph Ming <josephming at ymail.com> writes:

> This might be an amateur question but how does tahoe protect caps once
> used by clients?
> By that I mean that it seems like if I wanted to attack a tahoe user,
> the easiest way in would be to try to capture someone's root
> read-write cap. That is stored locally on all that user's clients?
> What does tahoe do to protect that data? I looked at the android
> client and see that it gets stored as a resource. I believe resources
> are siloed away on that platform from other processes so it should be
> safe assuming the device hasn't been rooted or have apps that get in
> through a security hole in the platform, and that it doesn't fall into
> the wrong physical hands. Most mainstream OSes don't silo in the same
> way, so any process run by a user might be able to access that value
> if it is stored in a file right? So maybe my attack vector would be to
> get a piece of malicious software installed alongside tahoe, to try to
> pick off that cap value and send it to me?
> I've seen the criticism of using the web interface for the same reason
> http://www.lexort.com/blog/tahoe-lafs.html#sec-4_1. Is that valid? If
> so, that's an even bigger hole, but I'm not worried about that
> one. It's easy to avoid using the browser as an interface to tahoe.

It's a fair question that has not had extensive discussion.

The prevailing notion is that clients are trustworthy and storage
servers are untrusted.  Of course, people realize that this might not
match everyone's threat models - but it seems to be the most-common
threat model.

It's hard to imagine a filesystem that could safely make files available
on untrustworthy clients.  (One could do something like use time-limited
tokens to make read/write only last some number of hours, but that
doesn't remove access during enabled times.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110801/7605224a/attachment.asc>

More information about the tahoe-dev mailing list