1 |
On Sun, 26 Sep 2004 02:14:35 -0400 |
2 |
John Richard Moser <nigelenki@×××××××.net> wrote: |
3 |
|
4 |
> |>2) The risk is real and errors against this seem common. |
5 |
> | |
6 |
> | |
7 |
> | Sure, there is risk in almost everything too. However just because |
8 |
> | driving an automobile can be dangerous doesn't mean I'll buy a tank or |
9 |
> | stay inside just to feel safe. |
10 |
> |
11 |
> No, but you'll get one with strong bars in the doors so taht side |
12 |
> impacts don't crush you to death, but rather push your car (crack open a |
13 |
> fiberglass car door once, you'll see 'em). Also, rollbars on cars with |
14 |
> no hard-top, etc. |
15 |
|
16 |
And to make analogies, wouldn't technologies such as ACLs, |
17 |
firewalls, VPNs, etc provide us with our side-impact bars, airbags, etc? |
18 |
|
19 |
Additionally just because wood burns doesn't mean people don't live in |
20 |
houses made from wood. |
21 |
|
22 |
> | Doesn't this exist already? if people didn't trust Gentoo then why |
23 |
> are| they using it? We can't be held ultimately responsible for |
24 |
> software we| didn't write. If you can knock over service foo-1.2.3 on |
25 |
> Gentoo, chances| are you can knock it over on another Linux or possibly |
26 |
> any other platform| it runs on either. |
27 |
> |
28 |
> I trust Gentoo in the security sense as much as I trust Mandrake, or |
29 |
> Debian, or SuSE. The difference is that after taking notice of the |
30 |
> hardened project, I learned about all kinds of neat stuff like |
31 |
> - -fstack-protector and PaX, and now don't really trust anything else. |
32 |
|
33 |
That is where you chose to define reasonable security for yourself and |
34 |
your applications. Imposing these options on the unknowing or unwary is |
35 |
not the best course of action, regardless of the "transparency" of those |
36 |
options to the user. |
37 |
|
38 |
> You can't be held responsible for others' security holes, but you can |
39 |
> take simple steps to mitigate the damages. |
40 |
|
41 |
This is something that each person needs to evaluate for themselves. |
42 |
Whether I agree or disagree with a given individual on what a default |
43 |
level of reasonable security is, the ultimate decision is up to the end |
44 |
user. |
45 |
|
46 |
Gentoo's role is similar to that of a consultant. You have the |
47 |
consultants research or investigate a problem, concept, etc and then they |
48 |
present you with the results, and the possible solutions to go |
49 |
with. The decision is still up to the end user, and with a consultant, |
50 |
they*know* what the pros and cons before making that decision. |
51 |
|
52 |
> |>What I propose to do (pick the low hanging fruit): |
53 |
> |>1) Add stack protector and and any similar 'features' stable in |
54 |
> hardened|>to the default CLFAGS of the gentoo install/profiles. By |
55 |
> stable I mean|>things which do not break the majority of functionality. |
56 |
> | |
57 |
> | |
58 |
> | Feel free to take on the ownership of making this work on every arch's |
59 |
> | toolchain then. Also feel free to deal with all upstream authors who |
60 |
> | start instantly dismissing any bugs from Gentoo due to the fact that |
61 |
> the| toolchain is quite modified to accomplish this task. Take the |
62 |
> current| stance the GAIM team has with us as an example of what would be |
63 |
> to come. |
64 |
> |
65 |
> SSP works on all architectures. |
66 |
|
67 |
The concept of SSP may work on all architectures, but the implementation |
68 |
requires a fair amount of work to make it happen. Getting the toolchain |
69 |
and/or commonly used applications to build and/or run properly when SSP is |
70 |
in use has proven to be a problem in the past. If you want exact |
71 |
historical evidence, just search our bugzilla server, particularly for |
72 |
SPARC (i.e. bug #.39725). |
73 |
|
74 |
Granted support for SSP gets better as time goes on, but using the Gentoo |
75 |
user base (unless they choose to be) as the QA for this is not a good |
76 |
idea. |
77 |
|
78 |
> As for upstream authors, guess what? |
79 |
> |
80 |
> |
81 |
> usr/lib/python2.3/site-packages/mx/TextTools/Examples/pytag.py:47: |
82 |
> SyntaxWarning: name 'debugging' is used prior to global declaration |
83 |
> |
84 |
> python: stack smashing attack in function symtable_node() |
85 |
> |
86 |
> error: command '/usr/bin/python' terminated by signal 6 |
87 |
> |
88 |
> |
89 |
> Well SHIT! Looks like I've got some MEANINGFUL information about a bug! |
90 |
> ~ I mean damn, I can tell you right in what function the CHARACTER ARRAY |
91 |
> that got overflowed was created, and that it was created on the stack |
92 |
> (char a[n]); this leads you of course to the fact that it had to be |
93 |
> overflowed by some function that got called from this function AND |
94 |
> passed a character array, or somewhere along the line where that |
95 |
> character array was passed. |
96 |
> |
97 |
> This is much more useful than "OMFG PYTHON R CRASH N STUFF WHEN I DO |
98 |
> STFUF!!!1@!2151!" |
99 |
|
100 |
Perhaps I need to clarify what I said earlier so it isn't taken the wrong |
101 |
way. The support issue I am thinking of here is more of the day to day |
102 |
problems with a package rather than discovered security vulnerabilities in |
103 |
a package. For instance, in the past we (being the SPARC team) have had |
104 |
issues with certain packages, even in the system profile, failing to build |
105 |
with -fstack-protector enabled. When running into problems like this |
106 |
where a package with a non-modified toolchain normally works, software |
107 |
authors are probably less likely to work to fix the problem unless the fix |
108 |
is given to them. |
109 |
|
110 |
I can't say I've heard of a case where SSP helped to find a |
111 |
vulnerability and an author chose not to fix it. |
112 |
|
113 |
Also while SSP will provide useful debug information, as you have |
114 |
illustrated above, to help work towards a solution to the problem, the |
115 |
average user who would have this enabled would have no real clue what |
116 |
these messages mean, or even file a bug report about them. And when a |
117 |
bug report is filed, a large majority of those bug reports due come in the |
118 |
form you've indicated above. |
119 |
|
120 |
|
121 |
> |>2) broken ebuilds can filter-flags until fixed (better approach since |
122 |
> |>you are only fixing up ebuilds for broken stuff and may also prompt |
123 |
> the|>devs to try and make the protection work). |
124 |
> | |
125 |
> | |
126 |
> | The protection itself is a work-around to the original problem. You |
127 |
> want| to continue to work around the problem even more? |
128 |
> | |
129 |
> |
130 |
> SSP is a work-around for buffer overflows that may or may not lead to |
131 |
> security exploits. |
132 |
> |
133 |
> Filtering in ebuilds is a work-around for bad software which gets killed |
134 |
> because it's self-overflowing; or for software that triggers potential |
135 |
> bugs in SSP (yes, SSP is software, written by humans, geniouses yes but |
136 |
> humans, and can have bugs). In the first case, of course, SSP tells you |
137 |
> almost exactly where to start looking. |
138 |
|
139 |
To reference this with the concern about trust, I would hope that part of |
140 |
the decision for the people with high levels of security in mind would be |
141 |
the security of the packages they choose to install. For instance, I'm |
142 |
probably less likely to install wu-ftpd over other ftp daemons because of |
143 |
it's historical problems with security bugs. |
144 |
|
145 |
> | |
146 |
> |>3) People who prefer not to be protected can remove the settings from |
147 |
> |>their CFLAGS |
148 |
> | |
149 |
> | |
150 |
> | Personally, I don't think opting out is the way to do this. Having |
151 |
> CFLAGS| that are in by default that may or may not work across all |
152 |
> architectures| is not a good thing. |
153 |
> |
154 |
> Opting out of a feature which in usage you're normally not going to |
155 |
> really notice is there is no the way to do things? Dude, that's like |
156 |
> saying you should make locks on windows optional. They can be unlocked. |
157 |
> |
158 |
> And ssp is supposed to be portable. Etoh and Yoda's paper[1] says that |
159 |
> The IBM stack smash protection method (ProPolice) is CPU and OS |
160 |
> independent[2]. I think that you'd be within reason to complain to them |
161 |
> if it didn't work accross all archs. |
162 |
> |
163 |
> [1] http://www.trl.ibm.com/projects/security/ssp/main.html |
164 |
> [2] |
165 |
> http://www.trl.ibm.com/projects/security/ssp/node4.html#SECTION00045000000000000000 |
166 |
|
167 |
See my above reply to your comment of SSP working on all architectures. |
168 |
Additionally, thanks for the links on SSP. |
169 |
|
170 |
> |>4) get stuff virus, spam, etc protection functional and leveraged into |
171 |
> |>the defaults in other words turn on those USE flags in the standard |
172 |
> |>profiles |
173 |
> | |
174 |
> | |
175 |
> | No thanks. I don't want to have to spend the first 24 hours or so of |
176 |
> | using my new"trusted" operating system opting out of all of the overly |
177 |
> | paranoid defaults. If I'm looking for a high level of security out of |
178 |
> the| box, I'll use hardened or OpenBSD. |
179 |
> | |
180 |
> | |
181 |
> |>A personal opinion: |
182 |
> |>Anyone who thinks that a speed tradeoff is too much for better |
183 |
> |>protection is crazy. Do us all a favor and play a go night of russian |
184 |
> |>roulette by yourself to get your thrills. |
185 |
> | |
186 |
> |
187 |
> 1. Within reason |
188 |
> 2. It has to actually affect speed. Overhead != speed |
189 |
> |
190 |
> | |
191 |
> | OK seriously, this kind of comment isn't needed. I'm not sure what |
192 |
> you| hoped to have accomplished by it, but I'm fairly sure it didn't |
193 |
> work.| |
194 |
> | As anyone who has spent 5 minutes in the security world knows, there's |
195 |
> a| fine line between good security and paranoia. You can lock your |
196 |
> system| down to high heaven and be sure that people won't get into it, |
197 |
> but then| you won't be able to do a damn thing either. What good is |
198 |
> that?| |
199 |
> |
200 |
> Yes, exactly. -fstack-protector is one of those things you put there |
201 |
> and never notice, but it does its job. |
202 |
|
203 |
As someone who supports our end users. I definitely have noticed it with |
204 |
regards to the afore mentioned build problems. |
205 |
|
206 |
> | Right now I have a choice to use these features if I want to. I don't |
207 |
> | have to "opt-out" and I would rather keep it that way. The support |
208 |
> | nightmare this will create is not worth the potential advantages. |
209 |
> |
210 |
> Yes and about 99.9999999% of your user base is probably going to say |
211 |
> "wha? SSP? Wassat?" if you ask them if they use SSP. |
212 |
|
213 |
This is a strong part of my point. |
214 |
|
215 |
One of the reasons I originally chose to run Slackware Linux and later |
216 |
Gentoo Linux is that they did not attempt to do things for the user by |
217 |
default. They assumed a certain level of knowledge by default, and let |
218 |
the users make their own choices. In having talked with many users of |
219 |
Gentoo either online or in the real world, this is one of the important |
220 |
reasons they chose to use Gentoo. |
221 |
|
222 |
To me, every time a proposal like this comes up that influences what the |
223 |
defaults are, it takes us one step farther away from that. |
224 |
|
225 |
> |>There's more to be said on security but I feel too lazy right now to |
226 |
> |>type it so if this isn't convinving you let us know. |
227 |
> | |
228 |
> | |
229 |
> | And as this list has shown historically, we can all argue security to |
230 |
> high| heaven with each party feeling they have the right answer and |
231 |
> never| accomplish anything. |
232 |
> | |
233 |
> | Now please don't get me wrong. As someone who's day job is in the |
234 |
> | security field, I very much like and appreciate the efforts that have |
235 |
> gone| into making secure toolchains and hardened systems a reality in |
236 |
> Gentoo.| In some cases I do use them as well. |
237 |
> | |
238 |
> |
239 |
> As someone who is passively absorbing this information, I find your |
240 |
> ignorance combined with your claim of being a security expert to |
241 |
> indicate that you're full of shit. |
242 |
|
243 |
You are certainly entitled to that opinion. I never claimed to be a |
244 |
security expert, I only said I worked in the field. And just because I |
245 |
work in the field doesn't mean I'm intricately familiar with everything in |
246 |
it. |
247 |
|
248 |
> You've repetedly referred to the issue of cross-platform portability |
249 |
> with SSP in here, for example; and I've pointed out once a link that |
250 |
> shows that SSP is OS and CPU independent. Do your research, read what's |
251 |
> out there. |
252 |
|
253 |
See my above mentioned historical problems with using -fstack-protector. |
254 |
What is written on paper and what actually happens in the real world are |
255 |
two entirely different things. |
256 |
|
257 |
> I also pointed out how SSP helps you find AND fix the problems, where |
258 |
> you just said it's a work-around and that upstream maintainers will use |
259 |
> it as an excuse to fix bugs. Instead of whining to them that shit |
260 |
> breaks and that they need to now find some way to reproduce the problem |
261 |
> OR just go audit their entire codebase over and over until they find it, |
262 |
> we can tell them EXACTLY where to start looking. We can ALMOST tell |
263 |
> them where the bug is. Doesn't this make life easier for all of us? |
264 |
|
265 |
Being able to give bug reports to upstream authors as much detail as |
266 |
possible is always a good thing, be it a regular type bug or a security |
267 |
bug. |
268 |
|
269 |
Yes I said SSP is a work-around. While it can help mitigate the risks of |
270 |
certain forms of attacks, and help to find a solution for them, it does |
271 |
not inherently fix them. The original problem itself still lies in the |
272 |
original daemon code. |
273 |
|
274 |
As for upstream maintainers issues with using the modified toolchain, the |
275 |
problem more revolves around build issues with -fstack-protector enabled |
276 |
for example. If it builds for the author and a majority of the users with |
277 |
their unmodified toolchains, but ours with -fstack-protector enabled fails |
278 |
to build the package, chances are the problem isn't going to receive a |
279 |
high level of attention unless the fix is provided. |
280 |
|
281 |
> This tells me you haven't done your research, haven't tested the system |
282 |
> and triggered it intentionally to see what happens, have only a rough |
283 |
> idea if any what you're dealing with, and thus have no place commenting. |
284 |
|
285 |
As perhaps I should have more clearly indicated in my first email, I'm not |
286 |
considering this from strictly a security standpoint. I'm considering |
287 |
this more from the perspective of someone who's role is to maintain an |
288 |
architecture for Gentoo. This requires myself and my team, as well as the |
289 |
other architecture teams, to extensively test a very large number of |
290 |
packages. |
291 |
|
292 |
As you get farther away from the more commonly supported architectures |
293 |
(x86 and PPC), the problems in the base toolchain, kernel or even a large |
294 |
number of packages grows quite significantly. However, the developer base |
295 |
for these other architectures is quite small (either with regards to |
296 |
Gentoo or without). With the introduction of this and possibly security |
297 |
technologies in the future into the default profiles, it leaves an already |
298 |
tight time schedule even more stressed. |
299 |
|
300 |
This is also one of the reasons we have herds, and not everyone is in the |
301 |
hardened herd. Enabling options such as this by default essentially does |
302 |
that to some extent in my mind, particularly for the Gentoo architecture |
303 |
teams. In an ideal world, it would be nice to have one or two developers |
304 |
from each architecture who could help to focus on improving security in |
305 |
Gentoo, but at the current time that isn't possible. |
306 |
|
307 |
Thankfully we have had some people in the past such as Method, |
308 |
solar and pappy who have done a tremendous job at first incorporating |
309 |
these technologies into Gentoo, and then help make them work for |
310 |
additional architectures. They can attest to the amount of work needed to |
311 |
actually get these options to fly as often toolchain components like gcc |
312 |
or glibc need some patching in order for this to happen. |
313 |
|
314 |
> I'm no security expert, I don't claim to be; but I at least know the |
315 |
> subjet matter here better than you, for some strange and unknown reason. |
316 |
|
317 |
That is entirely possible. I think some of this is due to us looking at |
318 |
it from different angles as well. |
319 |
|
320 |
> | However, I do not believe it is our place nor our job to make that |
321 |
> choice| for our users. You cannot protect people from themselves, |
322 |
> regardless of| the perceived benefits. |
323 |
> | |
324 |
> |
325 |
> I can say that faster. "General security is a lost cause; only security |
326 |
> experts have any business having security, even if it's transparent to |
327 |
> them." |
328 |
|
329 |
Like a lot of things in life, it pays to do your homework first. That's |
330 |
why I'm advocating the opt-in approach here. Similarly to the fact that |
331 |
we do not require users to use a syslog daemon (unless other |
332 |
applications they chose to use require it), but suggest it in the |
333 |
Installation Handbook, this could be an item to be put at the beginning. |
334 |
Both to inform the user as to what SSP is and how to enable it if they |
335 |
choose. |
336 |
|
337 |
This level of enhanced security can easily be negated by something as |
338 |
simple as social engineering too. Choosing to enable one form of security |
339 |
protection by default can quickly snowball into many forms, which may or |
340 |
may not be the right decisions for our regular, non-security minded users. |
341 |
|
342 |
Only by providing users with information and strongly urging them to |
343 |
read it can they be in the proper position to evaluate that. |
344 |
|
345 |
And while security is important to some people, it is not to others (yes |
346 |
this is an endlessly debatable topic, so lets leave it at that and not |
347 |
contribute to it). . If we are seriously thinking of implementing this, I |
348 |
would ask that we poll our end users first to see if this is a |
349 |
default option a majority of them would want or not. |
350 |
|
351 |
Regards, |
352 |
-- |
353 |
Jason Wever |
354 |
Gentoo/Sparc Team Co-Lead |