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 <[email protected]> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
