Kernel version tracking policy?

Is there any strategy behind the current efforts to support particular
kernel versions? I would think that most grsecurity users would want
both security and stability on their production systems. It would seem
to me that most of them would prefer to have the project's limited
resources devoted to targeting the most stable minor versions of the
vanilla kernel rather than the bleeding edge.

For example, right now 2.6.22 has just been released, but bugfixes are
still coming in to 2.6.20 (for which .15 was just released a few days
ago).  Instead of wasting effort on the faster moving bleeding edge of
2.6.22 (or even 2.6.21), why not focus your efforts on making releases
for the very last bugfix release of a particular minor version? 

For example, targeting the development in www.grsecurity.com/~spender
on 2.6.20.latest so that you can release a stable version for
2.6.20.last and have it be usable with confidence for people for a
long time. It would seem that this would make for both less work and
ultimately more stable releases. Maybe this is the plan now with
2.6.21, but it seems like it hasn't been the plan with prior releases.

Anyways, I'm really happy with grsecurity otherwise. Please keep up
the good work!

--

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

_______________________________________________

Re: Kernel version tracking policy?

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

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

yes, there is a strategy, if you want to call it that . it is
about minimizing the waste we have to spend on tracking the 'stable'
2.6 series (vs. developing new features). the fundamental question
to answer is about how often one should do a forward port in order
to track the changes in 2.6. my experience is that i'd be lost in
the woods pretty quickly if i skipped several versions in a row,
there's just that many core changes to code that PaX also patches
itself. not keeping up with them from release to release would result
in a disproportionally larger effort later to do a forward port. this
is not to say that the version by version tracking doesn't require
a lot of time already, but it's still less than the alternatives.
in short, the choice is between bad and worse ways of tracking 2.6,
the whole thing is fundamentally a waste but we have to live with it.

> 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
then. with or without grsecurity, it's the biggest security risk among
all linux versions. whenever you use 2.6, 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.

Re: Kernel version tracking policy?

_______________________________________________
grsecurity mailing list
grsecurity@...
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity

Re: Kernel version tracking policy?

The "security problem" is not related to functionality, but to the stability
and new code being inserted...

Since 2.6 have no "development branch" anymore, many people are changing it
everytime... the base code is changing so much quickly, many important
changes are done in the 'stable' version of the kernel and no one are trying
the security of this codes.

You can see many efforts to solve race conditions in drivers, integer
overflows in memory manager and many others...

cya,

Rodrigo (BSDaemon).

--
http://www.kernelhacking.com/rodrigo

Kernel Hacking: If i really know, i can hack

GPG KeyID: 1FCEDEA1

--------- Mensagem Original --------
De: Social Care <i.do.not.care@...>
Para: grsecurity@... <grsecurity@...>
Assunto: Re: [grsec] Kernel version tracking policy?
Data: 20/07/07 15:26

> On 7/20/07, pageexec@...
&lt;pageexec@...&gt; wrote:&gt;
On 13 Jul 2007 at 0:43, Mike Perry wrote:&gt; &gt; Is there any strategy
behind the current efforts to support
> &gt; &gt; particular kernel versions?&gt; &quot;it is less work to keep
track of development changes&quot;&gt; &gt; I would think that most
grsecurity users would want both&gt; &gt; security and stability on their
production systems.
> &gt; we said it before, but here it is again: don&#39;t use 2.6 in
such&gt; cases [...]&gt; you already decided to trade security for
features/etc and&gt; discussion of which 2.6.x to track for stability and
security
> &gt; misses the point.Honestly, I am not a skilled programmer. So I could
not offer mymanpower 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 conservativesecurity guys started babbling
how it is much more secure to staywith 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 listedadvantages of a 2.4 kernel of
version 2.6 regarding security.Could somebody please mention specific
features in a
> 2.6 kernelthat are more insecure compared to a 2.4 kernel?And about the
origin question of Mike Perry I would like to saythat I fully agree:The
cleanest grsecurity code is the latest version which depends
> on the relatively new kernel. But for the cleanest kernel codepeople
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 withthe stable release of debian.
Just two of multiple big problemsis the missing udev and acpi support.
> What is the advice of the experts?-- greetings from somebody who cares
about facts.
>
>
>
>
>
> _______________________________________________
> grsecurity mailing list
> grsecurity@...
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>

________________________________________________
Message sent using UebiMiau 2.7.2

Re: Kernel version tracking policy?

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.