I am interested too :) No C knowledge but strong linux background and very organized guy.
On Thu, 2008-02-21 at 01:05 -0500, Casey Link wrote: > It would probably help if we knew how many people were interested. > > I am. +1 > > Casey > > On Wed, Feb 20, 2008 at 10:16 PM, Eduardo Tongson <[EMAIL PROTECTED]> wrote: > > Alright how do we proceed to get this team started. > > > > ed*eonsec > > > > > > > > On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Wed, 2008-02-20 at 13:59 -0500, Harlan Lieberman-Berg wrote: > > > > On Sunday 17 February 2008 23:12:35 Robert Buchholz wrote: > > > > > On Sunday, 17. February 2008, Eduardo Tongson wrote: > > > > > > What specific kernel knowledge is needed to get a Kernel advisory > > up > > > > > > and running ? > > > > > > > > > > Between becoming aware of a vulnerability in Linux and drafting an > > advisory > > > > > for one or all kernel sources comes the part where you review which > > > > > versions of which kernel sources are affected and unaffected. You > > also > > > > > need to pay attention to specifics of the added patchsets, which > > might > > > > > duplicate vulnerabilities. > > > > > > > > > > Parts of the job can indeed be done without Kernel and C knowledge, > > but > > > > > some cannot. So if we draft a new kernel security *team*, people > > without C > > > > > and kernel knowledge are helpful -- some others need to have it, > > though. > > > > > > > > > > Robert > > > > > > > > To be honest, 99% of what is done in the kernel security team can be > > done with > > > > no C knowledge at all. > > > > > > > > I'm not an expert C person - far from it - but I eventually became > > the head of > > > > Kernel Security until I retired a few months ago. > > > > > > > > Most of it is bug handling. The major problem is a social, not a > > technical > > > > one. Because of the manner in which our kernels are organized, a > > single > > > > vulnerability involves checking upstream version numbers, > > coordinating them > > > > into our downstream version numbers for all sources, checking to see > > if the > > > > sources are effected, figuring out who to CC for the bugs, then > > harassing > > > > them until they do it. > > > > > > > > Unlike other security sources, any attempt to hardmask the package is > > shutdown > > > > instantly. The chaos that would result from a kernel hardmask, even > > one of > > > > the lesser used ones, caused me to only successfully order one over > > my entire > > > > career in Gentoo Kernsec... even though more around 30 would have been > > > > needed. It is not infrequently that bugs will last six months > > without any > > > > action coming about them, and users are blissfully unaware. > > > > > > > > I am happy to give my input as the former head of Kernel Security, > > but it is > > > > my personal opinion that any advances in kernel security will require > > the > > > > full cooperation of security, and letting the head of kernel security > > be able > > > > to actually enforce threats, as that seems to be the only way bugs > > ever get > > > > resolved. Pleading didn't work - I tried. > > > > > > > > -Harlan Lieberman-Berg > > > > Gentoo Developer Emeritus > > > > > > > > > Every word of what you said is painfully true. The only way to > > > accomplish this would be with an Iron Fist(fail) or a team of ~15 guys > > > who do nothing but patch and push new kernels and the PR that goes along > > > with them every few days. > > > -- > > > Ned Ludd <[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > > gentoo-security@lists.gentoo.org mailing list > > > > > > > > -- > > gentoo-security@lists.gentoo.org mailing list > > > > -- gentoo-security@lists.gentoo.org mailing list
