| |||||||||||||
|
| |||||||||||||
For what it is worth...For what it is worth...Posted Jan 9, 2005 2:33 UTC (Sun) by jd (guest, #26381)In reply to: poor social estrategy by PaXTeam Parent article: grsecurity 2.1.0 and kernel vulnerabilities Personally, I don't like getting into spitting-matches. I've singed myself on WAY too many flame-wars in the past, and my brain can't take it any more. However, that being said, I'll trow in my two units of local currency. I understand politics, the fights over who has to deal with what, etc. I understand them and I detest them. Which is easier for a person to do? Hit the "delete" button, or hit a "forward" button to get the message to the right person? Seems to me, it's still one button. So arguing "did it go to the right person" is largely missing the very point of such an argument. If it did NOT go to the right person, but DID go to someone who has to know who the right person was, why did it NOT get to the right person? Secondly, are we interested in who-did-what/who-didn't-do-what fights, or are we interested in Linux being the best OS that ever was and ever will be? If we are more interested in the latter, then someone should include the patches! It's that simple. At the end of the day, there's only one sure way of making progress, and that's to move forward. Lastly, do I think some of the security developers tend to be rough around the edges? Well, yes. I had a few fights on my hands, over including patches into FOLK that others wanted to keep to themselves. I included them anyway. Nobody, but NOBODY, is going to tell me that Linux users deserve second-best, should live in ignorance of what's out there, or should have the difficulties inherent in merging multiple patches. I wanted an easy showcase for technology, and that's exactly what I produced, whether others liked it or not. It was my opinion then, and still mine today, that knowledge is exactly like power - something to be distributed as widely as humanly possible, for the betterment of all. Sure, I'm crazy. Sure, if Linux were to include everything that was important to a substantial fraction of it's users, the kernel would be nearly twice the size it is now. But I can survive being crazy, and those who download source can survive a little longer download time. Neither of these will kill. If substantial, wholly justified, scares into Linux' security or stability hit the community, then those might very well kill Tux. I think the potential consequences make a LITTLE bit of effort by SOMEBODY in the Linux Kernel Development environ into getting Linus to install these patches, and in full, well worth any likely price. We can always back things out, if they turn out to be an error or become obsolete. Intermezzo, the original Ext FS, and a few other favourites have gone. DevFS is going to. Patches have been introduced with resistance from Linus - IIRC, he once said Linux would never run on anything but an ix86. All of these just show that nobody is perfect. But they also show that those who aren't perfect should allow themselves to be steered by others in areas they're not so skilled on.
(Log in to post comments)
For what it is worth... Posted Jan 10, 2005 8:33 UTC (Mon) by Wol (guest, #4433) [Link] "So arguing "did it go to the right person" is largely missing the very point of such an argument. If it did NOT go to the right person, but DID go to someone who has to know who the right person was, why did it NOT get to the right person?"
Simple. And also, what PaxTeam appear to be missing.
Linus is ONE person. There are only 24 hours in a day. There is a *high* probability that the PaxTeam message never got to Linus' eyeballs...
THAT is why there is all this maintainers/lieutenants business. To reduce the workload on Linus to the point where it is manageable.
PaxTeam isn't subscribed to LKML. Why? Because "there's too much"? Bearing in mind Linus probably gets a hell of a lot of mail addressed to him personally, then he has to keep an eye on LKML, then he actually has a job to do, then he has to discuss things with his lieutenants... I'm afraid a mesage from a total unknown has low priority. And that fact that it claims to report a security vulnerability is quite likely to get it classified as "crying wolf" - I bet loads of people do cry wolf - intentionally or down to their own incompetence.
At the end of the day, the "proper channels" are there for a reason - in other words the system would collapse if they weren't there. And the fact PaxTeam don't take LKML says just about everything else - Oh and if they don't know Andrea Arcangeli and/or Rik van Riel are the people to talk to about VM, then they haven't been watching kernel development. Who remembers the VM-wars of 2001? :-) Hint to PaxTeam - at the very least, read Kernel Traffic *in* *depth*.
Cheers,
For what it is worth... Posted Jan 10, 2005 11:26 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] lots of speculation so let's see the actual timeline a bit. spender emailed Linus sometime early december about the few issues he had found. he also mentioned some of the fixes that were in PaX, the result of one of them was this commit: http://linux.bkbits.net:8080/linux-2.6/cset@41bc900azV2y9... . understand please that we (well, spender at least) already had had a working two-way email connection with Linus. during the holidays i had finally time to work on the forward port of PaX (last supported version was 2.6.7) and that's when i realized the change in status of the expand_down() bug as since 2.6.9 it became exploitable by unprivileged users as well. so i emailed Linus about it (of the importance, not the bug itself, he had already known about it from spender, although he had never replied back on that one). one week later, which is early this year i resent the mail to Linus and Andrew as well, and the next day spender forwarded the mail himself to them (as i said, he had a known working email route to Linus at least). nothing happened except spender was preparing the next grsecurity release and it became more and more urgent to get some feedback on these issues. we were considering emailing Alan Cox (the week of waiting allotted to Andrew as well wasn't over yet) when the uselib() exploit suddenly hit the net and everyone entered forced release mode, we couldn't delay it either.
now that you know some background, tell me again, 1. how much more we should have waited, 2. why we shouldn't have contacted Linus/Andrew in the first place, 3. why we should have contacted Alan first (who is explicitly not the security contact anymore), 4. why we should have contacted a VM hacker first (none of whom is a security contact either, not even for their respective employer, let alone linux/VM in general).
see, i've been in the security industry for some number of years now, and i know quite well what best practices are (everyone's got his own, but there're some common elements):
rule 1: you contact the explicit security contact first. for linux this used to be Alan himself, nowadays it's vendor-sec (yes, that means you're not supposed to deal with individual distros, that's why vendor-sec was established in the first place). except they proved to unreliable, not to mention that it's *impossible* to contact them in a secure way (they don't have a PGP key).
rule 2: short of such a security contact, you begin contacting the 'people in control', from top to down, not the other way around. for companies that's relevant because the chain of control also represents the chain of responsibility. you can argue that open source/free software projects are free of chain of control, but they're not free of responsibility. i believed and still believe that we did the right thing when we began contacting Linus, then Andrew and were about to contact Alan when external events intervened.
> THAT is why there is all this maintainers/lieutenants business.
except the VM has no explicitly listed maintainer. but yes, i can guess who the main contributors are, but that doesn't make them a security contact (remember, we only wanted to get feedback, be told what to do next, and *not* to force Linus or anyone to actually manage the issue). it makes them the right person to actually fix the bug, but that's only the second step after the initial contact.
> PaxTeam isn't subscribed to LKML. Why? Because "there's too much"?
correct, i have a day job (unrelated to linux), family and friends, i can't handle that email load (and there's more in my world than lkml). i don't know where you got that i didn't like lkml, if i wasn't sympathetic to linux, i would have posted everything to bugtraq a month ago (contrast that to the recent DJB case).
> And that fact that it claims to report a security vulnerability is quite
i provided a proof of concept exploit (which you would know if you had actually read the announcement and posts here).
For what it is worth... Posted Jan 10, 2005 18:41 UTC (Mon) by geomon (guest, #27127) [Link] "lots of speculation so let's..."
From my perspective, you are trying to defend yourself when you shouldn't have to.
"understand please that we (well, spender at least) already had had a working two-way email connection with Linus. during the holidays..."
That is a problem. You have, of course, identified the source of the problem and have already recommended a solution.
"1. how much more we should have waited..."
For a legitimate bug? Not long I would hope (I am a user!).
"2. why we shouldn't have contacted Linus/Andrew in the first place"
You should have if there isn't an appropriate point-of-contact already established. That is the root cause of the problem.
"3. why we should have contacted Alan first (who is explicitly not the security contact anymore)"
You shouldn't have to. If Alan is not *the* person for security matters, that would be inappropriate as well.
"4. why we should have contacted a VM hacker first (none of whom is a security contact either, not even for their respective employer, let alone linux/VM in general)."
I've got to agree with this one too. Why should I go to the grocery store to get my car's front end aligned?
"see, i've been in the security industry for some number of years now, and i know quite well what best practices are (everyone's got his own, but there're some common elements)"
You are projecting defensiveness again. Give it a rest - you've made your point.
"rule 1: you contact the explicit security contact first."
WRONG!
An explict security contact should have been established *first*. That has either not happened yet, or the point-of-contact has changed. In either case, if the information is not readily available, then NO credible process exists for submitting security patches.
I share your shock at that prospect.
"for linux this used to be Alan himself, nowadays it's vendor-sec (yes, that means you're not supposed to deal with individual distros, that's why vendor-sec was established in the first place)."
That may work for individual vendors. How about establishing a Linux security working group that is composed of security contacts from the vendors?
What is missing in this discussion is a single point-of-contact, regardless of how it is composed, with contact information posted at kernel.org, kerneltrap.org, linux.org, or lwn.net.
"rule 2: short of such a security contact, you begin contacting the 'people in control"
WRONG.
See Rule 1.
"> PaxTeam isn't subscribed to LKML. Why? Because "there's too much"?
correct, i have a day job (unrelated to linux),"
And you shouldn't HAVE to subscribe to a mailing list to get a point-of-contact. That is pure stupidity.
That's why web pages were invented: "http://groups-beta.google.com/group/alt.hypertext/msg/395..."
"> And that fact that it claims to report a security vulnerability is quite likely to get it classified as "crying wolf"
i provided a proof of concept exploit (which you would know if you had actually read the announcement and posts here)."
The fact is, every event of security should be treated as a serious condition. It should not be the job of the submitter to determine whether the issue is serious or not; they may not be security experts but probably have noted a serious condition that they cannot explain by themselves.
This issue is a confidence buster if the community cannot produce a credible notification scheme. One of the key arguments that Linux advocates have used for years in defending the security of its products has been the claim that "many eyes" are better than code obfuscation. I have observed how this submitter has been treated and would question why ANYONE would submit a security concern to the community at this point.
Continuing to blame the person who submits the bug report, regardless of how they did it, is unacceptable. That smacks of the same arrogance that drove us to use Linux in the first place. Linux developers need to provide certainty to the user community that their concerns will be addressed and not arbitrarily dismissed.
Thoughts Posted Jan 10, 2005 19:49 UTC (Mon) by jd (guest, #26381) [Link] I hope that I'm not speculating too much, myself. The last thing I want to do is add to the general confusion, here. My personal opinion is that a bug is a bug is a bug, and needs to be fixed. Where that bug is a security hole, as is the case here, it needs to be fixed almost before any other concern, come hell or high water.There is very little value in a system that does everything superbly, with absolutely the minimum possible latency, total stability, yadda yadda yadda, if the next day some idiot turns you finely-honed silicon masterpiece into a spammer zombie. Yes, I think tempers may be running a little high, and that's probably not helping the situation. To me, there are only two issues at stake - how to get ALL of the fixes in place, ASAP, and how to ensure that future problems are addressed as fast as humanly possible.
For what it is worth... Posted Jan 10, 2005 21:30 UTC (Mon) by Ross (subscriber, #4065) [Link] There was no crying wolf and there were no "proper channels". If thesetype of bug reports are not taken seriously then I am shocked. It wasn't a subtle or complex set of bugs. These are the kinds of problems that show up all the time. The source code snippits should have been more than enough to "prove" their case.
As for reporting, the grsecurity team followed what they thought
Sure Linus gets a lot of email. He probaly doesn't read a lot of it.
They were very patient. People are claiming this is like DJB's arrogant
Someone else said that they shouldn't have mailed the kernel people but
Why can't MAINTAINERS have an entry for kernel security bug reports? Why
|
|
||||||||||||