[tahoe-dev] Fwd: [cap-talk] Don't put capabilities in argv?

[zooko]

On Jul 16, 2008, at 16:51 PM, Brian Warner wrote:

 > On Sat, 12 Jul 2008 21:29:30 -0700
 > Aleksandr Milewski <zandr at allmydata.com> wrote:

 > > We should allow a mechanism to keep caps off the commandline. We
 > > should also allow them, because they're convenient and the process
 > > table leak is not always a concern.
...
 > I agree. Being able to do 'tahoe get CAP' is awfully handy, and none
 > of the unix boxes that I use are shared with people I don't trust.

You two make good points.  I love using caps as the arguments to my
commands, and I love using unix processes as the executions of those
commands.  I personally would like to withhold judgment until I
understand better how to use the alternative(s).

 >  * maybe have 'tahoe get', etc, rewrite their argv to reduce the
 >    window of vulnerability.
 >  * fix #174 (which is about rewriting argv of 'tahoe start' to at
  >   least mention the directory in which the node is running)

#174 is valuable and important for ops, of course, but I don't think I
agree with the idea of "reducing the window of vulnerability".  Don't
you think that a window of vulnerability of a few ms is much worse
than leaving the data there in the process table for the whole process
lifetime, in the same way that Debian's 16-or-so bits of PRNG entropy
was much worse than zero bits of PRNG entropy would have been?

It is very hard to make it so that an attacker can't grab your caps.
It is very easy to make it so that users incorrectly think that it is
impossible for attackers to grab their caps.  (Not just users -- also
Tahoe hackers, people building new services on top of Tahoe, etc.)

Let's not head into that murky area -- let's have either complete and
obvious security or obvious insecurity with respect to other processes
running on the machine.

Regards,

Zooko