poor social estrategy
poor social estrategy
Posted Jan 8, 2005 22:45 UTC (Sat) by sbergman27 (guest, #10767)In reply to: poor social estrategy by PaXTeam
Parent article: grsecurity 2.1.0 and kernel vulnerabilities
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.
Posted Jan 8, 2005 23:05 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (12 responses)
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.
Posted Jan 8, 2005 23:36 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (11 responses)
"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?
Posted Jan 9, 2005 0:18 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (10 responses)
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.
Posted Jan 9, 2005 0:51 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (7 responses)
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,
Posted Jan 9, 2005 17:13 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (6 responses)
Posted Jan 9, 2005 22:07 UTC (Sun)
by dw (subscriber, #12017)
[Link] (4 responses)
Posted Jan 10, 2005 12:13 UTC (Mon)
by coolian (guest, #14818)
[Link] (3 responses)
Posted Jan 10, 2005 12:29 UTC (Mon)
by zorgan (guest, #4016)
[Link] (2 responses)
Posted Jan 11, 2005 8:11 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
After all, it was *Andrea* that *wrote* the thing in the first place, not Linus...
Cheers,
Posted Jan 11, 2005 20:11 UTC (Tue)
by zorgan (guest, #4016)
[Link]
Posted Jan 10, 2005 13:07 UTC (Mon)
by philips (guest, #937)
[Link]
I've being hitting this bug (as bug, but not securinty hole) several times before.
I hope that now it will be fixed.
Posted Jan 9, 2005 1:36 UTC (Sun)
by zorgan (guest, #4016)
[Link] (1 responses)
Posted Jan 9, 2005 12:48 UTC (Sun)
by PaXTeam (guest, #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?poor social estrategy
If you go to google (it's at http://www.google.com) and do a search on:poor social estrategy
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.poor social estrategy
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.poor social estrategy
Steve Bergman
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.poor social estrategy
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
Just remember, the Pax guy is trying to do a good thing, and wants it keep the pissing contests for IRC
fixed. 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.
May I politely request that everybody stops confusing the PaX team with keep the pissing contests for IRC
the 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.?
Why's it funny that "Andrea would be more of a VM mainainer than Linus"?keep the pissing contests for IRC
Wol
Because *writing* != *maintaining*. keep the pissing contests for IRC
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.
Thanks for you work, PaX.poor social estrategy
It always seemed to me that Alan Cox is very responsible with respect to Alan Cox?
security problems. Now that he is maintaining a stable kernel again, he
might be a good contact point.
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).Alan Cox?