permissions on files containing secrets

[zooko]

A unix user wanted a tahoe node to belong to a set of unix accounts instead of a single account, and he used unix groups to set up the permissions, but tahoe foiled him by executing "chmod(secretfile, 0600)" on several secret files.

​http://allmydata.org/pipermail/tahoe-dev/2007-December/000254.html

There are a couple of ways that we could enable this kind of usage without exposing the secret files by default to "other". One is just change the constant in our chmod lines to 0660. Nowadays, the default group tends to be quite small -- typically just the same user, so that should be safe.

Oh, I just realized that the way we are doing this is a race condition. An attacker could read the contents of the secret file after we've written it but before we've chmodded it. Oops. (I checked, and we do not currently make sure to chmod the file before writing secret data into it in every case. This should be fixed immediately.)

Perhaps we should chmod the tahoe basedir itself instead of specific files. That would solve the race condition, and perhaps make it slightly easier for unix users to adjust the permissions manually.

Alternately, we could create a subdirectory inside the basedir named "private". This appeals to me because I like to share information which isn't secret -- the other parts of the tahoe config and state can be examined by other users for their edification. It also helps document to the user which files they ought to be more careful with.

[warner]

I wasn't able to tell if the original user wanted to run multiple instances of the same tahoe node, or if they wanted to have a single instance be startable by any member of a group of users. Multiple instances of the same node is a no-no, since the tubids must be unique.

Here's the response I wrote on this topic:

It's important to remember that there can only be one instance of the node running at a time. The "node.pem" file (which holds the private key used by this node) is what directly determines the "node id" (just a hash of the corresponding public key), and the nodeid needs to be distinct for each node in a Tahoe grid.

Allowing multiple node processes to use the same key material would result in a very confused grid, in which there are multiple entities with the same nodeid. Since nodes only accept or create one connection per nodeid, this would mean most of your nodes won't be able to talk to each other.

I'm curious about your motivation: do you have several users (all in the same group) who want to share files with each other using tahoe? If so, the recommended approach is to have each user run their own node, one process per user (each with its own basedir and node.pem, etc). If your goal is to allow them to share a common virtual directory, then just have one of them create a new directory, then cut-and-paste the FURL of that directory to the others. Once everybody has added that FURL into their own private vdrives somewhere, they can all read and write to it equally, each through their own node.

Or perhaps you are concerned about resource utilization, and only want to have one tahoe node running on your computer even though you don't know ahead of time which user is going to want to use it. In this case, you might consider having one designated user start the node and leave it running for a long period of time, perhaps by using a crontab "@reboot" entry to automatically launch it at boot time. (note that this might be a special account dedicated to this purpose, much like the 'lp' account is used to run the printer-control daemons in most unix systems). The multiple users can then all access the same HTTP "webport", by copying the relevant URLs out of the 'start.html' file. That start.html file will be chmod'ed go-r by the first user, but that won't stop them from making a group-readable copy of it for everyone else. This approach gives multiple users a way to share the same tahoe node, meaning they all get the same private vdrive directory and that the grid has no way to distinguish between them.

[zooko]

My impression was that it was a simple matter of sharing the "start/stop/restart" button.

In the allmydata.com operations, we accomplish this by having a separate user account, and everyone who should have access to the start/stop/restart button gets the password to that user account.

Francesco and his friends can't create user accounts on their machines, so they tried to accomplish the same sharing using unix group permissions.

That's my reading of it.

[zooko]

Okay, even if we don't want to or can't facilitate (my interpretation of) Francesco's use case, we still have an open security problem here -- secret data is written into files while they are world-readable, and then they are chmodded to no longer be world-readable.

One way to fix this is to check the five or so places where we do this and make sure it is right in each place.

Another way that might be nicer would be to create a subdirectory of the basedir named "private", and chmod go-x that directory. This is is nicer because:

• we're more likely to handle sensitive files correctly from now on if we do it this way
• it provided built-in documentation to the use who inspects their .tahoe directory about which files are sensitive
• it could facilitate my interpretation of Francesco's use case, by allowing Francesco to do chmod g+x .tahoe/private.

Anyway, we need to do something for v0.7.0 release.

[zooko]

P.S. Oh yeah, and let's redefine all the files containing secrets to live inside the private subdirectory, too.

[warner]

Ok, we decided that we'd write a Node.get_or_create_private_config(), which always prefixes its filename with "private/", creates the private/ directory if necessary, and chmods it to 0700 the first time it is created. Then we change the various places that do their own 0600-chmod to use this method instead.

• allmydata.client: control_furl_file: this is a furlfile that provides access to the 'control port', mostly used by automated tests. We'll need to update those tests to look for private/control.furl instead of just control.furl
• allmydata.logpublisher: the logport furlfile. This will be maintained by foolscap, but we need to tell foolscap to use private/logport.furl instead of just logport.furl . There are also tools (flogtool tail) which can accept a directory and look for DIR/logport.furl: those tools will need to be invoked differently
• allmydata.node: certfile : this should really be chmodded by foolscap, but for now simply doing Tub(certFile="private/blah.pem") is fine
• allmydata.webish: start.html: the Welcome page needs to point the user at their BASEDIR/private/start.html file, instead of BASEDIR/start.html

Also, there should be a $basedir/private/README.private that explains *why* this directory is chmodded this way.

[zooko]

I'll do this.

[zooko]

fixed by a983f6d60c49d71b