Gentoo Archives: gentoo-security

From: Peter Simons <simons@××××.to>
To: gentoo-security@l.g.o
Subject: [gentoo-security] Re: Let's blow the whistle
Date: Mon, 08 Nov 2004 17:17:51
Message-Id: 87vfcgmfa8.fsf@peti.cryp.to
In Reply to: Re: [gentoo-security] Re: Let's blow the whistle by Dan Margolis
1 Dan Margolis writes:
2
3 > [the Gentoo security process is] designed solely to
4 > promote the absolute best security we can offer, never to
5 > save face or gain marketshare.
6
7 Good. I have a proposal how to the security of the
8 distribution could be enhanced by a bit. I have posted it 4
9 times by now. It would be way cool if the proposal would
10 find entry into the Gentoo security process so that a rather
11 fundamental problem in the distribution process can be
12 fixed. If there is a better way of doing things than what I
13 have suggested, then I am all ears. Doing nothing, however,
14 is not an answer I am prepared to accept and as of now I
15 have no indication that this problem is being solved or even
16 taken seriously.
17
18
19 > And of course, if a user wants to see it fixed, that user
20 > can always submit a patch.
21
22 I cannot submit any patch. There is no "patch". There is a
23 3-line shell script which someone who has administrator
24 privileges on the main server can put into the crontab, and
25 there is some GPG key which someone with administrator
26 privileges on the main server has to create. I can do
27 neither of that.
28
29
30 > But I'm not clear on what *your* goal is here by making a
31 > public stink.
32
33 My goal is to remedy a vulnerability in the Portage system
34 that has not been addressed for the last 1.5 years even
35 though it was known.
36
37
38 > I have to wonder, for the amount of time you're spending
39 > on this, couldn't you just write the patch yourself at
40 > some point and save a lot of trouble?
41
42 Add the key
43
44 ssh-dss AAAAB3NzaC1kc3MAAACBANHjGfHMVluJJEabXHuVvsmbbXu9hcC3G0KCU4RNGNR14tnv4FeDWIUZumrXfQ0V13D1zbOyw3IyEHTYVP7E1TNw+uEb7CjyGJY2TEyEROlDJ37mh5h8LVOrZbVZY/xHsNBgDiZccGKPkOwLcEzLiFJuDhMiQF67/Mzm69FVmCT9AAAAFQDpFMaASINIbv2ugG8R500QKz5ipwAAAIAZFWUJ5oU0p0zinH8Dk7V8SRXGtRr4LSWbncP1sza7AtQ+3RjtFfnPihAcjDJjzYw2rPeu+M140l3okB3A5P399XEW6pPuXW9wJVJLxJG4vZpsqHYrX6OX6kOjBBqU5RvPnWvXpKlUsYdJ3ZllDq5rmH0u26BBe7htsrhQzJPP/gAAAIEAmeN415RrRv95EVxFqpGIa7KqhIjktlLYVyy+8pFHoE1DV7MCaresaRAXTzHPpzHhU8mQ19MDObDZIhWnA9y5Qqk4UIUl7/8vF76FuCPEdsRZk5NX8GlIJAo0ghxKxdAJfHC+YGRSHL/l7eLS5WH//5vuw6egAl40UuwpEyF4O50= simons@×××××××××.to
45
46 to ~root/.ssh/authorized_keys on the appropriate machine,
47 let me know how to log in, and I'll do it. I am serious.
48
49
50 > So if it seems we're unresponsive, or unhelpful, or don't
51 > fix everything you'd like, just try sometimes to be a
52 > little more understanding.
53
54 I would be a lot more understanding if this weren't about
55 the machines of completely clueless people who use the
56 system and have no idea at all what kind of risk they take
57 every time they update their portage tree. If nobody has the
58 time to fix this soon, then post a public security advisory,
59 and I'll back off immediately.
60
61
62 Thierry Carrez writes:
63
64 > [You] think there is an easy solution that can be set up
65 > really quickly that will mitigate that risk. So you're
66 > not happy because you don't get why we don't already
67 > include your solution.
68
69 Could we please STOP speculating about my feelings,
70 motivations, or deficits as an individual and address the
71 problem?
72
73
74 > [Please] note that hose attacks are not that easy to
75 > perform and that you probably have a lot to worry about
76 > if you have someone malicious controlling all network
77 > flow and DNS information to your machines. Saying this
78 > doesn't mean I am ignoring the risk you talk about. I'm
79 > just putting it in perspective.
80
81 I think it would be better to let the users -- who's
82 machines are at stake here -- decide whether they feel this
83 is a risk worth taking. Make the flaw public and explain
84 what it means, and we'll see what the community thinks about
85 the feasibility of man-in-the-middle attacks.
86
87
88 > Now on to your solution. As the funny guy with the beard
89 > says, security is a trade-off, it's not a binary status.
90 > We are not "unsecure" now and we'll not be "secure" with
91 > your solution applied. The risk here is that [...]
92
93 I understand the risk, I know what it means, I know how it
94 can be exploited, and I don't need it explained to me.
95 However, there are several thousand users out there on the
96 Internet who may not know about it.
97
98
99 > [Your solution] does not mitigate the (supposed lower)
100 > risk of having the main rsync mirror compromised, the
101 > Gentoo CVS tree poisoned by unauthorized users, or
102 > getting a corrupted master public key from your
103 > man-in-the-middle controlling-all-network-flow bad guy.
104
105 Duh, of course it does not. What is your point? It doesn't
106 solve every problem we have, so better not do it at all?
107
108
109 > First, this added security layer will mean that for all
110 > users (including those who don't care) the speed of
111 > availability of software through portage will be a bit
112 > lower.
113
114 Make a separate mirror then, which has signed and
115 authenticated contents that is updated only once a day, once
116 a week, whatever. Then those who care can use the secure
117 system with slower package availability and those who don't
118 care can stick with the insecure but fast version. Right now
119 there is no way to choose.
120
121
122 > How much time does it take to generate MD5 (+ probably
123 > SHA1 I suppose) of every file in portage ?
124
125 On my system it took a bit over 4 minutes. I have no idea
126 how fast your machines is. But we'll never find out unless
127 we try it.
128
129
130 > How much time does it take to do MD5+SHA1 verification of
131 > every single file in /usr/portage after the rsync is
132 > complete ?
133
134 I'd guess about as long as it takes to generate them. Those
135 you don't care can disable it.
136
137
138 > An optional FEATURE ? Letting the no-clue users out of
139 > protection is not nice, but I suppose it's needed by your
140 > solution.
141
142 The unfortunate truth is that you cannot protect users who
143 don't have a clue (because they don't verify the GPG key to
144 begin with), so I don't have a problem with making this
145 functionality optional.
146
147
148 > Last, your simple solution means work for the
149 > infrastructure team [...]
150
151 _Any_ solution will mean work for the someone. No solution
152 will mean a LOT more work once it turns out a couple of
153 systems have been compromised, because then you'll have
154 hundreds and hundreds of people like me flooding your
155 mailing lists with questions and complaints.
156
157
158 > It's not your job to do an implementation proposal ?
159 > That's the "Gentoo team" job ? Man, get real. Gentoo is a
160 > community distribution.
161
162 I keep hearing that over and over again, yet "Gentoo" seems
163 to be awfully unwilling to pay attention to the community
164 when it tries to help. Just so that we don't forget the
165 facts: One and a half years, guys. I have posted ... I dunno
166 ... maybe 30 messages to this list by now? How much progress
167 have we made so far?
168
169 Let's get to work. Tell me what problem there is with my
170 proposal and I'll see whether I have ideas how to improve
171 it. Tell me a proposal of your own and I'll try to help
172 finding flaws in it. Give an account on the machine in
173 question and I'll to implement it.
174
175 Get this problem fixed or make it public and there is no
176 need for me to be "public stink".
177
178 Peter
179
180
181 --
182 gentoo-security@g.o mailing list

Replies

Subject Author
Re: [gentoo-security] Re: Let's blow the whistle Aiko Barz <aiko@××××××.de>
Re: [gentoo-security] Re: Let's blow the whistle Marius Mauch <genone@g.o>