Re: [gentoo-security] Kernel Security + KISS

[Sune Kloppenborg Jeppesen]

On Thursday 21 February 2008 13:35:52 Eduardo Tongson wrote:
> 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?

For those interested try dropping by #gentoo-security on Freenode and talk to 
rbu, I think he's spoken with a few interested already.

After Fosdem this weekend I hope to catch up a bit on the kernel situation.

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Gentoo Linux Security Team
http://security.gentoo.org

>
>   --  ed*eonsec
>
> On Thu, Feb 21, 2008 at 5:54 PM, Peter Hjalmarsson <xake@×××××××××.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@g.o> 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@g.o>
> >  > >
> >  > >
> >  > >
> >  > >  --
> >  > >  gentoo-security@l.g.o mailing list
-- 
gentoo-security@l.g.o mailing list