1 |
On Monday 14 April 2003 20.49, scrllock@××××××××××.com wrote: |
2 |
> On Mon, 14 Apr 2003 11:47:14 +0100 |
3 |
> |
4 |
> taviso <taviso@××××××××××××.org> wrote: |
5 |
> > The obvious issue is security, what stops a client returning work |
6 |
> > that is trojaned, and might allow compromising the host? |
7 |
> |
8 |
> In cvs for distcc they currently have ssh support. You have some excellent |
9 |
> ideas, this would be a very interesting project. |
10 |
> |
11 |
This is interesting and could be one of the parts needed. |
12 |
|
13 |
Security analysis |
14 |
--------------------- |
15 |
With untrusted hosts you to perform trusted computation you have need |
16 |
of a bit of gaming theory and a secure channel with a kind of authentication. |
17 |
The need for the secure channel is of course only to ensure that an attacker |
18 |
able to intercept communication to your machine cannot replace/change |
19 |
information when it's close to you. |
20 |
|
21 |
Furthermore each distcc must authorize to a central server which holds a |
22 |
root certificate onto which we have placed trust. This certificate is then |
23 |
used to certify that the IP-address the node claims to use is indeed the |
24 |
truth. |
25 |
If we can't trust the IP-address we cannot determine where the node is |
26 |
and it could for all we know be one machine intercepting and relaying |
27 |
all traffic to or from our computer and thus it could masquerade itself |
28 |
as beeing the entire distcc network. |
29 |
|
30 |
There are probably more issues to be resolved also as security is never easy. |
31 |
|
32 |
Trusting one root cert is also vulnerable to DOS attacks and this must be |
33 |
handled also. |
34 |
|
35 |
All these problems are generic problems for secure grid computing with |
36 |
unsecure nodes. There should be a lot to learn from looking at that kind |
37 |
of projects. |
38 |
|
39 |
There is also a risk that a poisoned ebuild could be used to break into other |
40 |
machines on the network. Under some circumstances it might be possible |
41 |
for an attacker go get an ebuild accepted which when built with specific |
42 |
flags etc will try to exploit local privilege escalation vulnerabilities. And |
43 |
by specifying a specific set of dependencies could target itself against |
44 |
vulnerable machines. I'm not sure how hard this would be to do but it could |
45 |
possibly be done and should be considered. |
46 |
|
47 |
Performance/Load balancing |
48 |
------------------------------------ |
49 |
On the performance side we have to worry about latencies and pipelining, but |
50 |
that should be solvable. It'd also be interesting to examine the possibilities |
51 |
of using a dist ccache and try to submit the works in a fashion that keeps |
52 |
the ccache's up to date and the load of the nodes somewhat fair. |
53 |
|
54 |
A slow machine gets a higher load by compiling the same amount of code as |
55 |
a faster machine. So the load balancing should be performed based on the |
56 |
actual time spent on a task. |
57 |
|
58 |
Whatever strategy is used the application must have good bandwith/cpu |
59 |
allocation rules. Preferably the user should be able to select certain |
60 |
application/situations where bandwith/cpu should be throttled. For a |
61 |
start this could be made as shell-scripts to be used for starting such an |
62 |
application. |
63 |
|
64 |
Interesting usages |
65 |
--------------------------------------------------------------------------------------------- |
66 |
I see two interesting usages for this kind of setup rather than simply doing |
67 |
distcc over a wan to speed up single package installs. |
68 |
|
69 |
|
70 |
1) Building for QA, this would let the developers harness our CPU to |
71 |
efficiently try new ebuilds out with several different setups. If each new / |
72 |
updated ebuild was built on 10 different configurations some errors would |
73 |
be caught earlier. |
74 |
2) Feeding a download network where precompiled binaries |
75 |
are stored with a hash of something that uniquely enough identifies a binary. |
76 |
This value probably must be dependant on package, version, cflags, arch, |
77 |
useflags, env-vars. |
78 |
|
79 |
|
80 |
> -- |
81 |
> gentoo-dev@g.o mailing list |
82 |
|
83 |
|
84 |
-- |
85 |
gentoo-dev@g.o mailing list |