[tahoe-dev] can the web browser be used securely to manage your data? Re: Tahoe-LAFS is widely misunderstood
Greg Troxel
gdt at ir.bbn.com
Thu Feb 3 07:20:24 PST 2011
"Zooko O'Whielacronx" <zooko at zooko.com> writes:
> Our fix for Nathan's exploit was to remove a convenience feature which
> provided ambient authority in order to reduce the user's exposure to
> visible capabilities. (That convenience feature was a URL path
> "http://$HOST/vdrive/" which the gateway would map to your root
> capability for you. This is exactly like the "tahoe:" alias that we
> later added to the CLI, except for the WUI.)
>
> Now, perhaps you, gentle reader, will draw a different lesson from the
> same empirical evidence. If you draw your alternative lesson well
> enough, you can win your own “I Hacked Tahoe-LAFS!” t-shirt. :-)
The WUI issue is related to another cap-handling issue, and I think it
helps to talk about them together. Normally, one uses local unix
permissions and stores a rootcap in .tahoe/private/aliases. But the
rootcap is really akin to one's passphrase to mount a cfs volume (or
truecrypt/encfs, for those not as old as I am). So leaving it in the
local filesystem is really only one security model which says: I don't
trust the cloud, but I do trust the hosts from which I access tahoe.
In many ways this is the only sane position, but there's a big
difference between "this machine doesn't have a keylogger" and "my caps
are on this machines backup tapes".
So, there probably should be some way to unlock caps protected with a
passphrase, much like ssh-agent or gpg-agent. Then, the way caps are
used in browsers becomes obviously more problematic: in typical usage
the browser remembers caps and stores them in .mozilla/firefox/blah/blah
somepalce.
An interesting step would be to change the WUI to treat capabilities as
passwords rather than form values. My two worries are:
firefox remember caps by default
firefox is too big to be non-scary to handle secrets. sometimes it's
too hard to resist, but tahoe doesn't feel architecturally like one of
those times.
So a valid attack would be:
get control of a computer on which someone has used tahoe in the past
(accessing the WUI with a browser), and get at their files.
-------------- 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/20110203/aa518c8d/attachment.pgp>
More information about the tahoe-dev
mailing list