[tahoe-dev] question about sharing...

[Zooko O'Whielacronx]

Brian wrote many correct and useful things here, and below I'm mostly
responding only the parts for which I have minor quibbles or
additional comments. When I explain things in detail, below, I'm
mostly talking to the general reader of tahoe-dev rather than to
Brian. Brian usually doesn't need me to explain things to him...

On Sun, Jun 5, 2011 at 2:16 PM, Brian Warner <warner at lothar.com> wrote:
>
> the Confused Deputy Attack, which happens when someone
> gives you a designation for an object (e.g. a filename) which they can't
> touch, but which you can, and it's too hard for you to determine whether
> they had the right to touch that object or not.

The way I remember the Confused Deputy Attack is always to remember
Norm Hardy's original description of it [1]. His paper is very short
and is readable.

In it, he describes a computer program which is a compiler-for-hire.
You give the compiler your source code and it gives you object code,
and it writes out a billing record to tell its owner how much to bill
you for.

The customer who submits the program to be compiled specifies a source
file and an object file, and the compiler reads the source from the
first and writes the results to the second.

The attack is: the job submitter figures out where the billing record
will go that the compiler is going to write out for its owner, and
pass a pointer to that file as your second argument (the argument
which specifies the object file). The compiler will output the object
file to that location and clobber the billing record.

The way that capability security can fix this is to change the
interface so that you can't point at a file unless you have permission
to access it. For example in unix you could pass fds instead of
filenames, or in Tahoe-LAFS you could pass caps.

The owner of compiler could give the compiler a write-cap to a
directory into which the compiler could write the billing records, and
the submitter of the job could give the compiler a write-cap to a
directory into which the compiler could write the object files. Now
that whole class of attack is eliminated. But if the communication
between the compiler and the other programs includes pointing at
objects that they can't touch, then this class of attack is possible.

[1] http://www.cap-lore.com/CapTheory/ConfusedDeputy.html


> I think it's fair to argue that a revocable tool like this ought to be
> the primary user-facing sharing mechanism, and the raw readcap should be
> hidden from casual users. (the biggest downsides are complexity and the
> availability hit caused by a forwarder being offline). But we haven't
> gotten it done yet.

I don't think I agree. As far as revocation of read-access to
immutable files goes, I think providing that functionality to the user
would cause more harm than good by offering them functionality that
either can't be made reliable (if it is implemented by trying to
delete all distributed copies of the ciphertext), or that makes them
reliant on a single point of failure (if it is implemented by a proxy
operated by the sender that holds the real read-cap and gives out a
revocable cap to the recipient).

Ping Yee—a good thinker about usability and security—once looked at
the Tahoe-LAFS design and at this issue in particular, and his
suggestion was:

In the user interface, when there is an action you can take to share
read-access to an immutable file, then it is labelled as "send the
file to the recipient", not as "share a link to this file with the
recipient". Users already correctly understand that "sending" (such as
emailing a file to someone) is an irrevocable act, but that it does
not give that person access to future versions of that file.

Now as far as revoking read-access or write-access to *mutable*
things, then I agree we could improve Tahoe-LAFS usability a lot by
making that sort of revocation available to the user. It is a lot of
work, but would be a great improvement. Help needed! In my current
thinking, a good next step on this is ticket #954, which would enable
ticket #958.

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revoke write authority
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently


>  We started with the raw mechanism because you can
> build the revocable one on top of the raw one, but not the other way
> around. And there are different models you could build on top of the raw
> capabilities, whereas if we'd started with a
> traditional-in-the-unix-world user-account-based ACL system, those other
> models would be impossible.

This is also a good point.


> Yeah, currently the easiest form of this "revocable forwarder" is to use
> a mutable directory: you can't find out when it's been read, but you can
> delete the reference to prevent subsequent reads from working.

I don't think this is a good way to implement revocation of
read-access to an immutable file. The recipient can easily extract and
keep the direct reference. For example, I can send you a URL like
this:

http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html

That gives you read-access to a mutable directory. When you click on
that link, your Tahoe-LAFS gateway (or in this case the public demo
Tahoe-LAFS gateway running at http://insecure.tahoe-lafs.org) reads
that directory and follows a link in that directory named "blog.html".
That link takes you to an immutable file containing a particular
version of my blog.

When I update my blog with a new entry, then clicking on that link
will cause the gateway to take you to the new version (a new immutable
file). But, if you *wanted* to keep a link to the old version, it
would be very easy—just edit the URL and strip off the "blog.html" at
the end, resulting in:

http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/

Now go to that URL and you'll see the link to the immutable file,
labelled "blog.html". Click that link and you'll go here:

http://insecure.tahoe-lafs.org/file/URI%3ACHK%3Agy7djxyy7wtl3zjpja46vieaxq%3A3a7jbdizbmx62vbpovhbdn6difjw3yiksi6jqjf5kfjxnaylrzaa%3A3%3A12%3A908028/@@named=/blog.html

Now copy that URL or bookmark it, and from now on you'll always be
able to re-download that particular version of my blog.

In other systems (not Tahoe-LAFS) people sometimes do use this sort of
indirection as an attempt to provide revocation of read-access to
immutable files. It is basically a form of security by obscurity, such
as the way you can't necessarily save a flash video to disk unless you
use a specialized tool that knows how a particular flash video site
obscures its videos. If we wanted to go that way with Tahoe-LAFS, we
would start by hiding or obscuring the directory listing so that the
user couldn't easily examine the directory and see the immutable file
child link there. Let's not go that direction. :-)


> This is an unsolveable problem: there's a tradeoff between availability
> (before you revoke) and unavailability (after you revoke). If you only
> have one node holding the forwarder, then you can be pretty confident
> about your ability to revoke access, but when you *do* want someone to
> see the file, they're depending upon a single point of failure. If you
> spread the forwarder over ten servers (as mutable directories are), then
> you're highly likely to have access when you want it, but revocation
> depends upon being able to reach all ten servers.

That is a good point. Hm... now that I reflect upon this point for a
few minutes, there is another related trade-off here: are you relying
on the servers to obey your instructions or not? If you really want to
maintain revocability of read-access to immutable files, then you
probably have to make sure that you own and operate (and are the only
person who actually has root) on all of the servers. Or else you have
to remember that "whenever I decide to exercise my ability to revoke
read-access to an immutable file, it is really the folks who own and
operate and actually have root on the servers who get to make the call
as to whether my attempt to revoke succeeds".

On the other hand if you don't think of yourself as having the ability
to revoke read-access to immutable files, then you don't mind using
using a wider variety of servers. (Remote servers, servers for hire,
multi-tenant servers that you are sharing with other customers,
servers operated by your friends and family who probably don't have
military-grade infosec defense practices...)

Of course all of the above is relevant only if you decide to revoke
read-access to the immutable file before the first time anyone decides
to read the file. :-) After that point, all bets are off.

Honestly, implementing revocation of read-access to immutable files
seems like a high-difficulty and low-reward endeavour. I wish I knew
how to communicate to users that if they want a distributed system in
which they can use servers that they don't personally carefully
control, they need to relinquish their desire for this functionality.
How to communicate that? I think Ping Yee's idea is probably the right
idea: just make the button that does it in the user interface say
"Send" on it instead of "Share".

Regards,

Zooko