Kernel Security + KISS

After reading the tangent topic in bug id 209460 concerning
kernel
vulnerabilities and GLSAs I did some searching and
came across the "Kernels and GLSAs" thread from
awhile ago.

I understand the logic behind not including kernel
vulnerabilities in
regular GLSAs but in that thread
an up and coming solution (KISS) was mentioned. That was
back in 2005
and now according to the Gentoo Kernel Security sub-project
page the
project is stalled. Whatever happened to the KISS project?

I think notifying users of relevant kernel vulnerabilities
is
important and I would like to help if possible. What is the
current
state of things regarding kernel vulnerability reporting?


Casey Link
-- 
gentoo-securitylists.gentoo.org mailing list

On Feb 16, 2008 10:57 PM, Casey Link <unnamedramblergmail.com> wrote:
> After reading the tangent topic in bug id 209460
concerning kernel
> vulnerabilities and GLSAs I did some searching and
> came across the "Kernels and GLSAs" thread
from awhile ago.

And here's another one:

http://archives.gentoo.org/ge
ntoo-security/msg_b4dcb17d4fef48ce663b9352870be6a8.xml

I started this one, and share the same views as then.
It might be boring work, (and no, I can't do it - I'm just a
user of
Gentoo), but it's just strange to leave out the core on
which all
other packages utilise, and depend on.

Perhaps a compromise could be reached: Only serious
vulnerabilities,
in defaultly/commonly/always used parts of the kernel,
causing local,
or remote root escalations would be notified?

Ddos in raid-xyz.o on MIPS only in 2.6.16-rc2-mm-test -
doesn't matter.
local root in splice.c on x86/amd64 affecting 95% of kernel
users - does matter.

In fact, I'd prefer that to the old
create-a-GLSA-for-every-kernel-problem solution.

Anyway, it's late, and I'm tired, and I'm not detracting
from the
great job the security team do (and especially the Hardened
guys), but
it's nice to have just a one-stop-shop to know if you're
running
secure versions of things. (*Yes, having sources-x.y.z
installed
doesn't mean that you're running it, but at least it'll
force you to
install the sources to stop glsa-check from bitchin'  - and
then,
well, if you don't compile, build, and run it, well, that's
your own
fault. )

C

--
http://linuxvps.org/
-- 
gentoo-securitylists.gentoo.org mailing list

On Saturday 16 February 2008, Casey Link wrote:
> I understand the logic behind not including kernel
vulnerabilities in
> regular GLSAs but in that thread
> an up and coming solution (KISS) was mentioned. That
was back in 2005
> and now according to the Gentoo Kernel Security
sub-project page the
> project is stalled. Whatever happened to the KISS
project?
I sadly died before going live and the original kernel
developer left.

> I think notifying users of relevant kernel
vulnerabilities is
> important and I would like to help if possible. What is
the current
> state of things regarding kernel vulnerability
reporting?
I agree. However we need people with kernel knowledge and
time to handle 
security issues for all kernel sources.

Anyone interested should mail securitygentoo.org. 

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
-- 
gentoo-securitylists.gentoo.org mailing list

What specific kernel knowledge is needed to get a Kernel
advisory up
and running ?

   Ed

On Feb 18, 2008 1:46 AM, Sune Kloppenborg Jeppesen
<jaervoszgentoo.org> wrote:
> On Saturday 16 February 2008, Casey Link wrote:
> > I understand the logic behind not including kernel
vulnerabilities in
> > regular GLSAs but in that thread
> > an up and coming solution (KISS) was mentioned.
That was back in 2005
> > and now according to the Gentoo Kernel Security
sub-project page the
> > project is stalled. Whatever happened to the KISS
project?
> I sadly died before going live and the original kernel
developer left.
>
> > I think notifying users of relevant kernel
vulnerabilities is
> > important and I would like to help if possible.
What is the current
> > state of things regarding kernel vulnerability
reporting?
> I agree. However we need people with kernel knowledge
and time to handle
> security issues for all kernel sources.
>
> Anyone interested should mail securitygentoo.org.
>
> --
> Sune Kloppenborg Jeppesen
> Gentoo Linux Security Team
>
> --
> gentoo-securitylists.gentoo.org mailing list
>
>
-- 
gentoo-securitylists.gentoo.org mailing list

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

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
-- 
gentoo-securitylists.gentoo.org mailing list

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.

Very insightful. thanks..  I've no time to spare at the
moment so just
trying to brainstorm out loud.  Outside of the hardened
kernel what and
the various foo-kernel what's the benefit of not just
playing
follow-the-leader.  Maybe it's possible to just copy
something more well
maintained.. RH, Debian.. It would require Kernel security
maintain a
kernel, but then you'd never have to fight the maintainer
when you issue
a security fix which was pushed from upstream.  RH and
friend would even
guarantee it doesn't break things to some extent.  I'm sure
this has
been thought of before, but not sure why it's not
adopted....

./C

-- 
gentoo-securitylists.gentoo.org mailing list

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 <solargentoo.org>

-- 
gentoo-securitylists.gentoo.org mailing list

Alright how do we proceed to get this team started.

  ed*eonsec

On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd <solargentoo.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 <solargentoo.org>
>
>
>
>  --
>  gentoo-securitylists.gentoo.org mailing list
>
>
-- 
gentoo-securitylists.gentoo.org mailing list

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
<propolicegmail.com> wrote:
> Alright how do we proceed to get this team started.
>
>   ed*eonsec
>
>
>
>  On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd
<solargentoo.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 <solargentoo.org>
>  >
>  >
>  >
>  >  --
>  >  gentoo-securitylists.gentoo.org mailing
list
>  >
>  >
>  --
>  gentoo-securitylists.gentoo.org mailing list
>
>
-- 
gentoo-securitylists.gentoo.org mailing list