[grsec] Kernel version tracking policy?

[pageexec at freemail.hu]

On 20 Jul 2007 at 19:26, Social Care wrote:
> But one thing I would like to get cleared now, since these myths
> about 2.6 kernel insecurities exist since ages.
> 
> I personally have the feeling that 2 or maybe 3 very conservative
> security guys started babbling how it is much more secure to stay
> with a 2.4 kernel. And then the lot of wannabe experts started
> to pick up without being able to name any facts.
> 
> At least I never came across a trustworthy whitepaper that listed
> advantages of a 2.4 kernel of version 2.6 regarding security.
> 
> Could somebody please mention specific features in a 2.6 kernel
> that are more insecure compared to a 2.4 kernel?

notice that i was talking about 'security risk', not insecurity
per se (not that i hold 2.6 more secure than predecessors though).

risk is about judging the unknown and making decisions based on
that. anything before 2.6 has the advantage of not changing fast
therefore one can invest resources into verifying the codebase
and rest assured about a certain level quality for a long period
of time (for 2.4 that'd be easily years given how little it changes).

take 2.6 and the 20-30 MB of patches every release (that is, every
2-3 months) and you'll quickly realize that any such investment in
verification is pretty much a complete waste given the short lifetime
of the results (if one can obtain anything useful in 2-3 months to
begin with).

as for actual security, it's not only about features (did you mean
design bugs?) but implementation as well. for a design bug, look at
the suid coredump feature (CVE-2006-2451) that is just as buggy as
it was before the 'fix' last year, as soon as the sysadmin enables
it, his system is back to (a vulnerable) square one. for implementation
bugs, just look at the sheer amount of fixes in NPTL over the past
2 years, some of which are exploitable (at least for DoS) but were
sometimes fixed without mentioning that fact (so no CVEs).

in any case, do you *seriously* believe that hundreds of MBs of code
that entered 2.6 in its lifetime is *less* vulnerable than what we
had in 2.4 for the same amount of time?

> The cleanest grsecurity code is the latest version which depends
> on the relatively new kernel. But for the cleanest kernel code
> people advise you to go with an older but well tested kernel.
> This is a caveat.

the last 'older but well tested' kernel is 2.4, so i don't see where
you're disagreeing with me ;-). i assume you're not seriously saying
that a few months of 'in the wild use' amounts to 'well tested'.

> What if the newest grsecurity release would focus on the current
> kernel in the stable release of debian, for example?

every non-debian user would want to take your head, i guess.
fortunately for you, we're going to stick to vanilla ;-).

> Going by grsecurity and the 2.4 kernel is plain impossible with
> the stable release of debian. Just two of multiple big problems
> is the missing udev and acpi support.

that's a debian problem, not that of grsecurity. out of curiosity,
being a security conscious user (admin?), why are you advocating for
the one mainstream distro that has throughout all these years paid
the least attention to security? no ssp, no PIEs, no MAC, but lots
of GNU_STACK and textrels all over the place, hardened it is not,
and no amount of kernel patching will help that.

> What is the advice of the experts?

if you mean the conservative babblers (such as myself), i suggest
doing your own research before dismissing what they're saying.