Advertisement
Embedded Android Training, Hands-On
AOSP, Kernel Androidisms, System Server, Internals / 5-days / O'Reilly Author Instructor
| |||||||||||||
|
| |||||||||||||
For what it is worth...For what it is worth...Posted Jan 10, 2005 8:33 UTC (Mon) by Wol (guest, #4433)In reply to: For what it is worth... by jd Parent article: grsecurity 2.1.0 and kernel vulnerabilities
"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,
(Log in to post comments)
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
|
|
||||||||||||