[distcc] Proposed Enhancements/Changes

[Fergus Henderson]

On Wed, Jul 23, 2008 at 10:36 AM, Ihar `Philips` Filipau <
thephilips at gmail.com> wrote:

> Actually,  last time I was deploying distcc we had serious problems
> with the newly introduced security.


There's always going to be a trade-off between security and convenience.
But the default configuration has to be secure.

If you have any specific suggestions about what we can do to make things
more convenient without compromising security for the default configuration,
and without preventing those folks who do care about security from getting
it, please let us know.


> Personally, I would love to hear a case why the security in distcc
> (e.g. --allow) is needed at all.


>From the distcc security page <
http://distcc.googlecode.com/svn/trunk/doc/web/security.html>:

"*Anyone who can connect to the distcc server port can run arbitrary
commands on that machine as the distccd user. ...* Someone has written
a program
to attack unprotected
servers<http://www.metasploit.com/projects/Framework/modules/exploits/distcc_exec.pm>
."
That's why the --allow option is now mandatory in distcc 3.0.

Distcc normally is deployed on corporate LAN which is already behind
> firewalls/etc.


An important principle of security is don't put all of your eggs in one
basket: don't rely on a single layer of defence.  Instead, it's good
security practice to have multiple layers of defence.

Often it is possible for attackers to breach a corporate firewall.  If you
have distccd in an insecure configuration (e.g. older versions of distccd
running without using the --allow option to restrict the IP addresses that
can connect), then an attacker who gains access to any host behind the
firewall could connect to any of the distcc server machines and could run
arbitrary commands as the distcc user on those distcc server machines, thus
escalating what could be a minor breach into a major breach.  An attacker
might be able to find further security weakness on any one of the distcc
server machines, thus escalating the breach even further.

VPN is the proper solution, from my
> POV, making all the security enhancement in distcc (1) obsolete and
> (2) needless hurdle for users.


Because of the need for multiple layers of defence, using a VPN does not
make the security enhancements in distcc obsolete.

In addition, using a firewall and/or VPN is no protection against insider
attacks, whereas the /etc/distcc/commands.allow facility (which the distcc
service startup code uses to set DISTCC_CMDLIST before invoking distccd)
does provide some level of protection against insider attacks (albeit much
less than using ssh mode).

Cheers,
  Fergus.

-- 
Fergus Henderson <fergus at google.com>
-------------- next part --------------
HTML attachment scrubbed and removed