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]>
> > >
> > >
> > >
> > > --
> > > [email protected] mailing list
> > >
> > >
> > --
> > [email protected] mailing list
> >
> >
--
[email protected] mailing list
