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