| 1 |
Brian G. Peterson wrote: |
| 2 |
|
| 3 |
> On Tuesday 20 September 2005 06:09 am, Calum wrote: |
| 4 |
> |
| 5 |
>>I prefer the idea that tracking one source (GLSAs) would provide me with |
| 6 |
>>all the information I needed to keep my Gentoo boxes secure, but if we |
| 7 |
>>were all to change to a new system, perhaps the kernel GLSAs should have |
| 8 |
>>overlapped with this new system until it was in, tested, and adopted? |
| 9 |
> |
| 10 |
> While I think that kernels do need additional information to be supplied about |
| 11 |
> a potential security hole (kernel security problems often occur in a module |
| 12 |
> that many people may not use), I agree that kernel vulnerabilities should be |
| 13 |
> published as GLSAs. |
| 14 |
|
| 15 |
We used to do GLSAs about kernel issues but then we faced major |
| 16 |
problems. The main one was that we issue GLSAs when vulnerabilities are |
| 17 |
fixed in the tree, to tell people to upgrade to a fixed package. But if |
| 18 |
we wait until all kernel sources are fixed in Portage, the GLSA wasn't |
| 19 |
out for months after the vulnerability was disclosed. Secondary problems |
| 20 |
were due to the fact that kernel issues were piling up in the meantime, |
| 21 |
so when you do issue a GLSA, it didn't cover the recent vulnerabilities |
| 22 |
but just told about some that were fixed months ago. So we kept on |
| 23 |
pushing back the GLSA release date... It just wasn't a solution. |
| 24 |
|
| 25 |
We tried to produce GLSA with shorter release time (like ignore the |
| 26 |
sources that weren't security-reactive) but that meant like a kernel |
| 27 |
GLSA per week because Local DoS issues are found all the time. You just |
| 28 |
couldn't upgrade the kernel and reboot every time a GLSA like this would |
| 29 |
go out. We needed a system that would help you make the right decisions |
| 30 |
of when to upgrade your kernel (and which kernel to use) rather than |
| 31 |
encourage people to reboot as much as Windows users. |
| 32 |
|
| 33 |
About glsa-check integration, it's not a solution either. glsa-check |
| 34 |
checks currently installed packages, not the running kernel. If you |
| 35 |
removed the affected sources package, it would tell you you aren't |
| 36 |
affected, while you were. If you follow the glsa-check instructions and |
| 37 |
emerge the "fixed" sources, it would tell you you're affected until you |
| 38 |
remove the affected sources package, and doesn't care if you really |
| 39 |
compiled a kernel with the fixed sources... |
| 40 |
|
| 41 |
So we realized kernel security is an ongoing process that needs ongoing |
| 42 |
security information rather than point releases. The KISS system is |
| 43 |
up-to-date with vulnerabilities rather than with fixes, meaning you get |
| 44 |
to know which vulnerabilities affect you with your currently-running |
| 45 |
kernel. Then you can make an informed decision of when you should |
| 46 |
upgrade (when enough vulnerabilities you care about have been fixed), |
| 47 |
and to what sources version you should upgrade. The system lets you |
| 48 |
ignore the things that don't matter to you (personal workstations do not |
| 49 |
care much about Local DoS vulnerabilities). |
| 50 |
|
| 51 |
This ongoing kernel security information, along with kernel security |
| 52 |
alerts when really big things are discovered (Local Root that would work |
| 53 |
on most configurations, for example) was for us the best solution. KISS |
| 54 |
is almost ready for BETA release, meaning you should be able to access |
| 55 |
it very soon for testing. |
| 56 |
|
| 57 |
Also KISS was no secret, it's in the Security project objectives for |
| 58 |
year 2005, as published on this list at the beginning of the year. |
| 59 |
|
| 60 |
Thanks for your attention. |
| 61 |
|
| 62 |
-- |
| 63 |
Thierry Carrez (Koon) |
| 64 |
Operational Manager, Gentoo Linux Security |
| 65 |
-- |
| 66 |
gentoo-security@g.o mailing list |
Archives