| |||||||||||||
poor social estrategypoor social estrategyPosted Jan 8, 2005 16:22 UTC (Sat) by sbergman27 (guest, #10767)In reply to: poor social estrategy by PaXTeam Parent article: grsecurity 2.1.0 and kernel vulnerabilities
The proper procedure has been well known for some time. Determine the official maintainers for the parts of the kernel in question and report the bugs or vulnerabilities to them. Linus and Andrew depend upon them heavily for the sake of their own scalability. (This was all hashed out back during the "Linus Scalability Crisis" of a few years ago.) If Linus or Andrew happen to be the official maintainers for the relevant part of the kernel, then the reporter has cause to complain.
But it is important to understand that one can't just pick up the "Bat Phone" and have Linus or Andrew on the other end. Those days are gone.
I'm sure many would appreciate reporters of vulnerabilities following the prescribed procedures before subjecting the rest of us to increased (albeit temporary) risk.
None of this is to imply that most in the community do not appreciate the reporting of vulnerabilities, of course.
(Log in to post comments)
poor social estrategy Posted Jan 8, 2005 19:31 UTC (Sat) by PaXTeam (subscriber, #24616) [Link] i've got to love armchair bug reporters. where's the 'proper procedure' you're talking about? saying it exists doesn't answer my question, i want to know the details, URLs, etc. CREDITS says that Alan Cox was the former security contact point and vendor-sec is the new one which i don't trust for very good reasons (i'll remind you again of the uselib() bug leak).
second, you're suggesting contacting the subsystem maintainer(s). to the best of my knowledge, the VM (to which expand_stack/mlockall belong, i think) has no such person, nothing relevant turns up in MAINTAINERS at least. so that leaves Linus/Andrew. do i have a 'cause to complain' now?
third, i beg to differ on your assertion that i was the cause for your increased risk. if anyone subjected you to risk then it is the person(s) who didn't bother to deal with the bugreports (you realize that i even provided a patch which is now included in -ac verbatim). or as in the case of the uselib() bug, didn't do so in a timely manner.
poor social estrategy Posted Jan 8, 2005 22:45 UTC (Sat) by sbergman27 (guest, #10767) [Link] VM? Andrea Arcangeli. ( andrea@suse.de )
That's just off the top of my head. Being an armchair bug reporter, I can't be sure that the email address is current. I think it is, though. Get to know the procedures and relevant people. How can you guys maintain "grsecurity" and not know all this already?
On a side note, have you any relation to D. J. Bernstein?
There is a family resemblance.
poor social estrategy Posted Jan 8, 2005 23:05 UTC (Sat) by PaXTeam (subscriber, #24616) [Link] Andrea is a kernel hacker, he's not a security contact nor is he the maintainer of the VM (if you know otherwise, show me the proof). and you ditched my original question, so let me ask it again: what is the 'proper procedure' *you* were talking about?
as for DJB: DJB didn't give any time for the authors he notified (well, in case of nasm it was one day, but that was probably the exception, not the rule). contrast that to my 2-3 weeks and several emails to establish contact before going public. pick a better example next time.
poor social estrategy Posted Jan 8, 2005 23:36 UTC (Sat) by sbergman27 (guest, #10767) [Link] If you go to google (it's at http://www.google.com) and do a search on:
"vm maintainer" "linux kernel"
(and you can just hit "I'm feeling lucky" because it is the first hit),
you will get a "kernel trap" article.
You can just type "www.kerneltrap.org", though, because this particular example happens to be on the front page of today's kerneltrap.org, thought the article is from Dec 27, 2004.
And it mentions that:
"An interesting dicussion on the lkml examined the efficiency of the inode cache in the 2.4 Linux kernel [forum], discussing several tunables primarily helpful to systems serving large NFS or Samba mounts. In particular, a slowdown was reported on such a system easily reproducible by doing a find / while cat'ing large files to /dev/null. In a discussion between 2.4 maintainer Marcelo Tosatti [interview], 2.6 maintainer Andrew Morton [interview] and VM maintainer Andrea Arcangeli [interview], it was decided that this was likely due to too small of an inode cache hash table resulting in a large number of collisions. For the work case in question, some tunables looked to prove helpful. Going forward, effort might be made in 2.6 or beyond to improve the inode cache."
As to my ditching your original question. do you subscribe to LKML? Do you read it?
That's where I learned this stuff, and you should too.
You ditched my question, however. Why do the grsecurity maintainers, who just released exploit code in the wild without following prescribed procedures, putting us all at risk, not already know all this?(!) How much can we trust you?
poor social estrategy Posted Jan 9, 2005 0:18 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] thanks for educating me on how to use google, but what you failed to answer is how i was supposed to figure out that the 'proper procedure' for reporting a *security bug* in the VM means a google search for specific keywords and accepting the first hit (it made me smile no end, i suggest you post this to the bugtraq or dailydave lists and see what the real security community thinks about it). so try again. it also makes me think, would you really blindly accept the first hit as your point of contact for a security matter? i'm glad you don't get to make that call.
as for lkml, i'm not subscribed but sometimes i scan it for interesting posts/topics.
you keep accusing me (btw, i'm not a grsecurity developer, i develop PaX only) of not following 'prescribed procedures' yet you *still* haven't shown a *single* reference to said procedure. please, stop this generic mumbo-jumbo and just post the URL to the document that clearly and unambiguously describes the 'official' procedure for reporting linux security bugs (and which doesn't involve Linus/Andrew and prescribes >3 weeks of waiting time, else you'd just prove my point). short of that, you have no basis for your claims (how can i not follow something you don't seem to know yourself either?).
we'll talk about being responsible when you manage to answer the question above.
poor social estrategy Posted Jan 9, 2005 0:51 UTC (Sun) by sbergman27 (guest, #10767) [Link] No need. You have already stated your postition and mindset quite clearly enough for everyone to understand. And yes, I am exiting this thread, as I rather dislike participating in useless flamewars, which is what this has become.
I will, however, take this opportunity to agree with you that if such a document does not exist, it very much should. People should *not* have to read LKML to know these things. If grsecurity had not released exploit code to the world, I would even be sympathetic. However, when an organization actually releases an exploit, it needs to be held to higher standards than the average Joe. The research on proper proceedure needs to be done, and thoroughly.
If you wish, we can continue this discussion via private email. I'm at steve_AT_rueb.com.
Live Long and Prosper,
poor social estrategy Posted Jan 9, 2005 17:13 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] everything i discussed here very much belongs to the public and it shall stay so. i see you are quick to accuse others of being irresponsible but don't actually have the guts to apologize when your claims prove to be without merit. you also haven't realized that there are bigger issues here than the fate of a handful bugs, which is the whole point why we tested the waters with them only, not more critical stuff. some questions for you and the community to answer: why can the BSDs have a designated security officer and linux not? why can you communicate with said officers using proper encryption whereas you cannot with vendor-sec? why did nothing happen after the do_brk() bug/exploit leak more than a year ago so just in time history could repeat itself with the uselib() bug/exploit? why didn't you, Steve Bergman, complain about *that* yet? why is it acceptable that isec can release local root exploits with their advisories (which are anything but simple to understand and hence reproduce) but a few liner in assembly (trivial to reproduce) makes you scream 'irresponsible'? hipocrisy abound and you talk about holding others to higher standards.
keep the pissing contests for IRC Posted Jan 9, 2005 22:07 UTC (Sun) by dw (subscriber, #12017) [Link] If there is still a problem here, take it to e-mail, or IRC. LWN comment postings are not the place for it - remember your comments will probably exist here long after you cease to.
keep the pissing contests for IRC Posted Jan 10, 2005 12:13 UTC (Mon) by coolian (guest, #14818) [Link] Just remember, the Pax guy is trying to do a good thing, and wants itfixed. He may have the social graces of a walrus, but he's at least *doing* something about a problem. Stop ripping the guy and acting like armchair quarterbacks.
keep the pissing contests for IRC Posted Jan 10, 2005 12:29 UTC (Mon) by zorgan (guest, #4016) [Link] May I politely request that everybody stops confusing the PaX team withthe grsecurity developers? I haven't seem anybody of the PaX team "behaving like a social walrus" (not that I think this term would be fair to Brad Spengler, either). Anyway, the suggestion that Andrea Arcangeli would currently be more of a VM maintainer than Linus Torvalds or Andrew Morton is so funny that I don't understand why anybody took sbergman27 seriously. He has done important development on the VM a couple of times, but he has never adopted anything like a maintainer's role, AFAIK. But I think the main point remains (and that's why this discussion makes sense): If Linus and akpm get too much flooded with e-mails that they cannot even reply to a local DoS report within 3 weeks, then maybe they should appoint someone to be a security contact person? Someone who is willing to look into such reports, can judge their severity, and contact the relevant maintainers to review proposed patches etc.?
keep the pissing contests for IRC Posted Jan 11, 2005 8:11 UTC (Tue) by Wol (guest, #4433) [Link] Why's it funny that "Andrea would be more of a VM mainainer than Linus"?
After all, it was *Andrea* that *wrote* the thing in the first place, not Linus...
Cheers,
keep the pissing contests for IRC Posted Jan 11, 2005 20:11 UTC (Tue) by zorgan (guest, #4016) [Link] Because *writing* != *maintaining*.Maintaining means reviewing other people's patches, forwarding them to tree maintainers, making sure the code stays clean and well-documented, etc. Andrea has not even bothered much sending his own to Linus/Marcelo.
poor social estrategy Posted Jan 10, 2005 13:07 UTC (Mon) by philips (guest, #937) [Link] Thanks for you work, PaX.
I've being hitting this bug (as bug, but not securinty hole) several times before.
I hope that now it will be fixed.
Alan Cox? Posted Jan 9, 2005 1:36 UTC (Sun) by zorgan (guest, #4016) [Link] It always seemed to me that Alan Cox is very responsible with respect tosecurity problems. Now that he is maintaining a stable kernel again, he might be a good contact point.
Alan Cox? Posted Jan 9, 2005 12:48 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] yes, Alan used to be the security contact person, but according to MAINTAINERS, vendor-sec took over that role (for the worse, as the facts show). with that said, we did consider contacting him after having waited for weeks in vain, but unfortunately the sudden leak of the uselib() bug and exploit made it necessary to release a new grsecurity version (which was otherwise being finalized for release anyway).
|
|||||||||||||