[grsec] Kernel version tracking policy?

[Social Care]

On 7/20/07, pageexec at freemail.hu <pageexec at freemail.hu> wrote:

> On 13 Jul 2007 at 0:43, Mike Perry wrote:

> > Is there any strategy behind the current efforts to support
> > particular kernel versions?

> "it is less work to keep track of development changes"

> > I would think that most grsecurity users would want both
> > security and stability on their production systems.

> we said it before, but here it is again: don't use 2.6 in such
> cases [...]
> you already decided to trade security for features/etc and
> discussion of which 2.6.x to track for stability and security
> misses the point.

Honestly, I am not a skilled programmer. So I could not offer my
manpower to port one grsecurity release to older kernel versions.

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?


And about the origin question of Mike Perry I would like to say
that I fully agree:

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.

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

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.


What is the advice of the experts?


-- 

greetings from somebody who cares about facts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grsecurity.net/pipermail/grsecurity/attachments/20070720/0c0f7fd4/attachment.htm