1 |
Peter Simons wrote: |
2 |
|
3 |
> So why is the Gentoo team so incredibly reluctant to do |
4 |
> anything about it? |
5 |
|
6 |
I don't like your style, but I think I can get your point. The current |
7 |
system update setup is vulnerable to man in the middle attacks between |
8 |
the master rsync server and the end user. And you think there is an easy |
9 |
solution that can be set up really quickly that will mitigate that risk. |
10 |
So you're not happy because you don't get why we don't already include |
11 |
your solution. |
12 |
|
13 |
First, please note that hose attacks are not that easy to perform and |
14 |
that you probably have a lot to worry about if you have someone |
15 |
malicious controlling all network flow and DNS information to your |
16 |
machines. Saying this doesn't mean I am ignoring the risk you talk |
17 |
about. I'm just putting it in perspective. |
18 |
|
19 |
Second, "the Gentoo team" is not one person sitting in the dark and |
20 |
saying "No, you're wrong, period.". It's a large group of volunteers, |
21 |
and you'll find some of them (mostly security guys) have been battling |
22 |
for years to get a good and secure update mechanism in Gentoo. For some |
23 |
of them, security is highest prio, for others it's stability, for others |
24 |
it's performance, etc. That's why things are going on slowly. And |
25 |
frankly, we're way better now than we were a year ago. |
26 |
|
27 |
Now on to your solution. As the funny guy with the beard says, security |
28 |
is a trade-off, it's not a binary status. We are not "unsecure" now and |
29 |
we'll not be "secure" with your solution applied. The risk here is that |
30 |
someone controlling your network flow and/or poisoning Gentoo DNS |
31 |
information can execute code with root privileges on any machine doing |
32 |
sync and updates. Your solution mitigates that risk by securing the link |
33 |
between the master rsync server and the end user using a signed digest |
34 |
that is controlled at the end user level using a key downloaded by other |
35 |
supposedly secure means, and kept updated by other supposedly secure |
36 |
mechanism. |
37 |
|
38 |
This does not mitigate the (supposed lower) risk of having the main |
39 |
rsync mirror compromised, the Gentoo CVS tree poisoned by unauthorized |
40 |
users, or getting a corrupted master public key from your |
41 |
man-in-the-middle controlling-all-network-flow bad guy. |
42 |
|
43 |
This is not the ultimate solution but one which has the merit of being |
44 |
simple (from your point of view) to be set up and that secures a part of |
45 |
the chain that you feel is the easiest to corrupt. So it's a band-aid, |
46 |
waiting for something more serious (all tree file signing with |
47 |
individual dev keys) to get ready. We'll let the concern of whether |
48 |
applying such a solution will or will not slow down the set up of the |
49 |
real one true good but too-slowly-coming security mechanism to others. |
50 |
|
51 |
What are the trade-offs you forget because of your agenda ? I can think |
52 |
of two, and being a security-oriented person, I suppose others with a |
53 |
different agenda will find more. |
54 |
|
55 |
First, this added security layer will mean that for all users (including |
56 |
those who don't care) the speed of availability of software through |
57 |
portage will be a bit lower. We'll have to sync rsync with CVS, |
58 |
calculate the digest and sign it before having it replicated with the |
59 |
second-order mirrors. How much time does it take to generate MD5 (+ |
60 |
probably SHA1 I suppose) of every file in portage ? I would like to |
61 |
know. Some users might complain that the added security they don't care |
62 |
about because they don't think MiM attacks likely on their systems will |
63 |
slow software availability. Who cares it takes an extra 30 minutes ? |
64 |
Tell that to those who sync 4 times per hour. |
65 |
|
66 |
OK, next, the end user side. You'll have to hook up tree signature |
67 |
verification to portage directly, as portage somehow executes code it |
68 |
fetched from the network when updating metadata and performing profile |
69 |
updates. We have a very large bunch of users (obviously not on this |
70 |
mailing list) complaining that emerge sync is waaaay too slow. How much |
71 |
time does it take to do MD5+SHA1 verification of every single file in |
72 |
/usr/portage after the rsync is complete ? That also I would like to |
73 |
know. That would help evaluate the real tradeoffs your solution implies. |
74 |
An optional FEATURE ? Letting the no-clue users out of protection is not |
75 |
nice, but I suppose it's needed by your solution. |
76 |
|
77 |
Last, your simple solution means work for the infrastructure team (to |
78 |
change the rsync replication process, provide for CPU time to perform |
79 |
the digest etc... And the portage team (testing and releasing extra |
80 |
functionality controlled by a FEATURE most people won't activate because |
81 |
it slows down the emerge sync process). Rephrasing your proposal as : |
82 |
|
83 |
(1) infrastructure scripts to generate signed digest |
84 |
(2) portage patches including the FEATURE of glocal verification |
85 |
(3) hard data showing the performance hit server-side and client-side |
86 |
|
87 |
would certainly help us. It's not your job to do an implementation |
88 |
proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a |
89 |
community distribution. The "Gentoo team" cannot do everything, it needs |
90 |
user support. And yes, even posting a small script helps. |
91 |
|
92 |
-- |
93 |
Thierry Carrez |
94 |
Operational Manager, Gentoo Linux Security |