Brian G. Peterson wrote:
> On Tuesday 20 September 2005 06:09 am, Calum wrote:
>>I prefer the idea that tracking one source (GLSAs) would provide me with
>>all the information I needed to keep my Gentoo boxes secure, but if we
>>were all to change to a new system, perhaps the kernel GLSAs should have
>>overlapped with this new system until it was in, tested, and adopted?
> While I think that kernels do need additional information to be supplied about
> a potential security hole (kernel security problems often occur in a module
> that many people may not use), I agree that kernel vulnerabilities should be
> published as GLSAs.
We used to do GLSAs about kernel issues but then we faced major
problems. The main one was that we issue GLSAs when vulnerabilities are
fixed in the tree, to tell people to upgrade to a fixed package. But if
we wait until all kernel sources are fixed in Portage, the GLSA wasn't
out for months after the vulnerability was disclosed. Secondary problems
were due to the fact that kernel issues were piling up in the meantime,
so when you do issue a GLSA, it didn't cover the recent vulnerabilities
but just told about some that were fixed months ago. So we kept on
pushing back the GLSA release date... It just wasn't a solution.
We tried to produce GLSA with shorter release time (like ignore the
sources that weren't security-reactive) but that meant like a kernel
GLSA per week because Local DoS issues are found all the time. You just
couldn't upgrade the kernel and reboot every time a GLSA like this would
go out. We needed a system that would help you make the right decisions
of when to upgrade your kernel (and which kernel to use) rather than
encourage people to reboot as much as Windows users.
About glsa-check integration, it's not a solution either. glsa-check
checks currently installed packages, not the running kernel. If you
removed the affected sources package, it would tell you you aren't
affected, while you were. If you follow the glsa-check instructions and
emerge the "fixed" sources, it would tell you you're affected until you
remove the affected sources package, and doesn't care if you really
compiled a kernel with the fixed sources...
So we realized kernel security is an ongoing process that needs ongoing
security information rather than point releases. The KISS system is
up-to-date with vulnerabilities rather than with fixes, meaning you get
to know which vulnerabilities affect you with your currently-running
kernel. Then you can make an informed decision of when you should
upgrade (when enough vulnerabilities you care about have been fixed),
and to what sources version you should upgrade. The system lets you
ignore the things that don't matter to you (personal workstations do not
care much about Local DoS vulnerabilities).
This ongoing kernel security information, along with kernel security
alerts when really big things are discovered (Local Root that would work
on most configurations, for example) was for us the best solution. KISS
is almost ready for BETA release, meaning you should be able to access
it very soon for testing.
Also KISS was no secret, it's in the Security project objectives for
year 2005, as published on this list at the beginning of the year.
Thanks for your attention.
Thierry Carrez (Koon)
Operational Manager, Gentoo Linux Security
firstname.lastname@example.org mailing list