Re: [gentoo-security] Kernel Security + KISS

["Eduardo Tongson" <propolice@gmail.com>]

If no Gentoo developer comes forward, I volunteer myself. Seems
everybody is busy and overworked to even authorize an official team.
Any Gentoo developer who can share their 'a day in the life of the
Gentoo Kernel Security team' experience?

  --  ed*eonsec

On Thu, Feb 21, 2008 at 5:54 PM, Peter Hjalmarsson <xake@rymdraket.net> wrote:
> AFAICS the thing missing is a leader. Someone to make a starting point
>  for the followers to make use of (not necessary inside of gentoo, I
>  believe it can always be integrated later if there are devs enough to
>  pick things up and integrate), a place for him to collect and keep list
>  and contact with interested people (also to keep "me too"-noise from
>  this list).
>
>  This does not even have to be a integrated gentoo solution, am I right?
>  Anybody having a hosting space could host a db with the
>  information/advisories.
>  And the hosting one could let anyone he/she trusts write info to that
>  db.
>  That db could be like "This vournable exists, these are the problems,
>  these are the workarounds/patches and there are no fixed kernel
>  versions/these kernel versions are fixed" where info could be updated as
>  they get along.
>  And anybody that has the time and skill could write a applications that
>  fetch info from this db about the currently running kernel and presents
>  the user with the text "No known vournables" or "These vournables
>  exists" with links to the information in the db about that advisory.
>  This way a user can run the application, get a message, read the
>  advisories and decide "I need to update to at least this version" or "I
>  do not need to update".
>
>  The thing needed after that is persons to keep this db up to date and
>  maybe bug devs to get fixed versions into portage.
>  But these people needs a central collection point where they could
>  "meet" and start moving things.
>
>  And anybody can bug any dev in bugzilla if a kernel is not fixed, but
>  the chances over-worked devs will notice and be more helpful if you are
>  more helpful with what, when and why this kernel thing should be fixed
>  (i.e. come well prepared).
>
>
>  tor 2008-02-21 klockan 11:16 +0800 skrev Eduardo Tongson:
>
>
> > Alright how do we proceed to get this team started.
>  >
>  >   ed*eonsec
>  >
>  > On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd <solar@gentoo.org> 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 <solar@gentoo.org>
>  > >
>  > >
>  > >
>  > >  --
>  > >  gentoo-security@lists.gentoo.org mailing list
>  > >
>  > >
>