Kernel security updates

[hlieberman]

I am currently a Gentoo Security Apprentice, and I trained under plasmaroo in terms of kernel security. Unless someone more competent than I is willing to step in, I'd be happy to take over Kernel Security.

[dsd]

please email me (dsd@gentoo.org)
_________________
http://dev.gentoo.org/~dsd

[dsd]

[kadeux]

Hi dsd,
thank you for your response.

[dsd]

on the kiss screenshots, the phrases "Latest Most Secure Version" and "Fixed Version" are in different contexts.

latest most secure is talking about the whole kernel, e.g. 2.6.16.26 is the latest most secure version of xbox-sources
fixed version is talking about individual security issues within a certain kernel, e.g. bug 133465 is fixed in version 2.6.16.18 of xbox-sources

the latest most secure version of xbox-sources is simply the 'highest' entry in the fixed version list for that particular kernel.

to answer your questions, there is no concept of a real security issue vs a theoretical non-exploitable issue. it's either a security issue in the mind of the kernel security guy, in which case it appears on KISS, or its not, in which case it doesn't appear there.

we do not mark significantly newer versions stable to pull in security fixes. if a security bug is found today in 2.6.17 which is fixed in 2.6.18, then we would not stable 2.6.18 in response, because that would result in a large change and we aren't quite ready for 2.6.18 to go stable yet. instead, we would backport the fix to the current stable branch (2.6.17) and mark the new version stable usually within 24 hours. yes, there will probably be a short period where the "latest most secure version" is not in the stable tree.

when fixing a kernel we don't immediately remove the older buggy versions from the tree. this is made difficult by the fact that the arch keywording is spread around and is slow to synchronize (when i update a kernel i can only mark it stable on x86, i have to ask arch teams to do the other keywords). also, some people are stuck with older kernels due to reasons like depending on a binary kernel module. we don't really support these users but we don't go out of our way to make things hard for them either (and typically security is not a concern for such users, they are inserting binary blobs into their kernel after all). having old kernels in the tree is also very useful for debugging. occasionally we get bugs like "-r3 had this issue but -r7 does not" and the fact that we have r4,r5,r6 still in the tree means that the user can test the intermediate releases with relative ease. that said, we do remove old kernels after some time to keep things clean-ish.

in your example, when 2.6.14-r8 is released, 2.6.14-r7 is left vulnerable to those security concerns. it is the users responsibility to upgrade. note that removing the ebuild is not a huge problem because portage will not give you an older version unless you explicitly ask for it, plus removing the ebuild would not accelerate the process of the user upgrading in any way.

there's another interesting point in your example which you didn't pick up on. there was a time when both hardened-sources 2.6.16 and 2.6.14 were being maintained and patched (i told you that we don't fix older versions). this was the choice of the maintainer at the time, but this stopped after a while. it resulted in a lot of work to keep things up to date, compare the size of the 2.6.14 patchset to the 2.6.18 one:
http://sources.gentoo.org/viewcvs.py/linux-patches/genpatches-2.6/historical/2.6.14/
http://sources.gentoo.org/viewcvs.py/linux-patches/genpatches-2.6/trunk/2.6.18/

the idea of maintaining old kernel branches like this is not something we are opposed to, but we lack the manpower to do it most of the time.
_________________
http://dev.gentoo.org/~dsd

[kadeux]

Hi dsd,
thanks for the clarifications. Your explanations are very helpful to make my decisions regarding kernel updates more well-substantiated.