On Wed, Jul 23, 2008 at 10:36 AM, Ihar `Philips` Filipau < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc