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 |