[distcc] Proposed Enhancements/Changes

[Martin Pool]

On 7/24/08, Fergus Henderson <fergus at google.com> wrote:
> On Wed, Jul 23, 2008 at 5:15 PM, Ihar `Philips` Filipau
> <thephilips at gmail.com> wrote:
>
> > My wish then would be to have a magic option (which might also throw
> > some warning into logs, to warn the lazy people like me about
> > consequences) to disable all security features altogether. e.g.
> > --security=off and default --security=on (or whatever popt can
> > handle).
>
> Well, if that's all you need, then it's already supported, with a slightly
> different syntax: instead of
>
>    distccd --security=off
>
> the syntax is
>
>    distccd --allow=255.255.255.255/32

Or in even less characters i think 0.0.0.0/0 will work.  iirc this is
in the manpage.

(I also recall some program that could be compiled with
-DGAPING_SECURITY_HOLE if you wanted...)

As well as untrustworthy people or compromised machines on corporate
networks there are also people on home networks that may be accessible
to the outside world.  I know of at least one person who has been
attacked this way despite the documentation, and there are automated
tools that will scan for and attack distcc machines.

I did measure using ssh as a transport and it is noticeably slower,
even with connection sharing.  The precise factor will depend on the
relative speed of cpu, memory, etc, but I think it should not be the
only way of having a reasonably secure connection.

It seems to me that a common situation these days is that there are
untrusted machines able to reach the server, but they are not able to
intercept traffic.  (Maybe this is unrealistic, I suppose intercepting
it may be possible with arp spoofing.)  In that case just a shared-key
or challenge-response authentication would be enough.  At least this
would defeat public internet scans for distcc servers.

If it turns out that most of the features of ssh are needed then it
would be better to work out how to use that efficiently than to
duplicate it.

It would also be interesting, though nontrivial, to take the approach
in djb's recent "10 years of qmail" paper and run each individual job
in a separate uid.  (Somewhat reminiscent of Erlang processes.)  Of
course this needs some kind of privileged helper.

It might also be good for distributors to arrange for distccd to run
in a chroot...

-- 
Martin <http://launchpad.net/~mbp/>