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