Re: [gentoo-dev] opt-in distributed portage network

[Mikael Andersson]

On Monday 14 April 2003 20.49, scrllock@××××××××××.com wrote:
> On Mon, 14 Apr 2003 11:47:14 +0100
>
> taviso <taviso@××××××××××××.org> wrote:
> > The obvious issue is security, what stops a client returning work
> > that is trojaned, and might allow compromising the host?
>
> In cvs for distcc they currently have ssh support. You have some excellent
> ideas, this would be a very interesting project.
>
This is interesting and could be one of the parts needed.

Security analysis
---------------------
With untrusted hosts you to perform trusted computation you have need
of a bit of gaming theory and a secure channel with a kind of authentication.
The need for the secure channel is of course only to ensure that an attacker
able to intercept communication to your machine cannot replace/change
information when it's close to you.

Furthermore each distcc must authorize to a central server which holds a
root certificate onto which we have placed trust. This certificate is then 
used to certify that the IP-address the node claims to use is indeed the
truth.
If we can't trust the IP-address we cannot determine where the node is
and it could for all we know be one machine intercepting and relaying
all traffic to or from our computer and thus it could masquerade itself
as beeing the entire distcc network.

There are probably more issues to be resolved also as security is never easy.

Trusting one root cert is also vulnerable to DOS attacks and this must be
handled also.

All these problems are generic problems for secure grid computing with
unsecure nodes. There should be a lot to learn from looking at that kind
of projects.

There is also a risk that a poisoned ebuild could be used to break into other
machines on the network. Under some circumstances it might be possible
for an attacker go get an ebuild accepted which when built with specific
flags etc will try to exploit local privilege escalation vulnerabilities. And 
by specifying a specific set of dependencies could target itself against
vulnerable machines. I'm not sure how hard this would be to do but it could
possibly be done and should be considered.

Performance/Load balancing
------------------------------------
On the performance side we have to worry about latencies and pipelining, but
that should be solvable. It'd also be interesting to examine the possibilities
of using a dist ccache and try to submit the works in a fashion that keeps
the ccache's up to date and the load of the nodes somewhat fair.

A slow machine gets a higher load by compiling the same amount of code as
a faster machine. So the load balancing should be performed based on the
actual time spent on a task.

Whatever strategy is used the application must have good bandwith/cpu 
allocation rules. Preferably the user should be able to select certain 
application/situations where bandwith/cpu should be throttled. For a 
start this could be made as shell-scripts to be used for starting such an
application.

Interesting usages
---------------------------------------------------------------------------------------------
I see two interesting usages for this kind of setup rather than simply doing
distcc over a wan to speed up single package installs.


1) Building for QA, this would let the developers harness our CPU to 
efficiently try new ebuilds out with several different setups. If each new / 
updated ebuild was built on 10 different configurations some errors would
be caught earlier.
2) Feeding a download network where precompiled binaries
are stored with a hash of something that uniquely enough identifies a binary.
This value probably must be dependant on package, version, cflags, arch, 
useflags, env-vars.


> --
> gentoo-dev@g.o mailing list


--
gentoo-dev@g.o mailing list