tahoe-lafs/trac

permissions on files containing secrets #219

New issue

Closed

opened 2007-12-01 16:57:21 +00:00 by zooko · 7 comments

zooko commented

2007-12-01 16:57:21 +00:00

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.

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.

zooko added the

labels 2007-12-01 16:57:21 +00:00

zooko added this to the undecided milestone 2007-12-01 16:57:21 +00:00

zooko changed title from ~~stop calling chmod()?~~ to facilitate sharing a tahoe node with a unix group

2007-12-01 16:57:55 +00:00

warner commented

2007-12-01 20:06:02 +00:00

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.

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 commented

2007-12-04 03:55:14 +00:00

Author

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.

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 commented

2007-12-06 15:01:53 +00:00

Author

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.

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 modified the milestone from undecided to 0.7.0

2007-12-06 15:01:53 +00:00

zooko changed title from ~~facilitate sharing a tahoe node with a unix group~~ to permissions on files containing secrets

2007-12-06 15:01:53 +00:00

zooko commented

2007-12-06 15:02:29 +00:00

Author

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

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

warner commented

2007-12-12 00:22:11 +00:00

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.

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.