[distcc] Proposed Enhancements/Changes

[KELEMEN Peter]

* Ihar `philips` Filipau (thephilips at gmail.com) [20080723 16:36]:

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

As far as I know, distcc has not been formally audited by an
independent security researcher and there was talk of possible
security problems many years ago (before 3.0rc, no new version had
been released for four years).

> Distcc normally is deployed on corporate LAN which is already
> behind firewalls/etc. All the security doesn't help against
> possible abuses or simply incorrect scripts polling in tight
> loop servers. And that's are the problems which people are
> experience most often.

You're correct.  However, some people have corporate LANs so
big and diverse that they have to treat it as untrusted anyway.
Eventually, we have an expected user base in the hundreds, in
diverse locations and end system security.

> Authentification? Accounting?? Why? This are only toy for admins
> and hurdle for people who use distcc.

Having those available optionally wouldn't hurt the small users
but would certainly help people that have to deal with bigger
installations.

> It is pretty pointless to put distcc on open net nor it is a
> usual deployment scenario. And even if you put distcc on open
> net, then you have much severe problem with your source code
> flying over the net, open to any cracker wishing to take a look
> inside. (*) I can't imagine company which would ever allow
> it. VPN is the proper solution, from my POV, making all the
> security enhancement in distcc (1) obsolete and (2) needless
> hurdle for users.

An “open net deployment” is your assumption.  We are looking
into ways of consolidating “guerilla” distcc clusters into a
centrally managed service.  We have a corproate network of tens
of thousands of IPs and our user base is a diverse scientific
researcher community in the field of particle physics.  Having
hundreds (potentially thousands) of users means you have to have
a grip on the service, who's using it and how they are using it.
Authentication, accounting and client zeroconf are pretty much
necessary for running a smooth centralized service.

> (*) Or even worse case, when cracker hijacks the TCP connection
> and sends back to client the object file with rogue code
> embedded. I would never allow distcc on open net for the reason
> alone.

Nor would we.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen at cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'