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 |