grsecurity forums

Yes I know, this question arises whenever a new kernel gets released...
But I just want to get some clarification on grsecurity's support for the 2.6.x kernel branch.
It seems to me that a lot of time passes between a kernel release and a grsec patch release, if any. What if new kernel exploits are discovered, I would be stuck using an old 2.6 kernel just to keep grsecurity, but that would not make much sense because that kernel isn't anymore that secure, so it would perhaps be more secure to get the newest kernel without (sigh) grsec...
Is it the dev's choice to snob the 2.6 kernel, or are there any difficulties writing the patch for that branch?
I'm sticking to kernel 2.4.x for now...

Hal9000 wrote:It seems to me that a lot of time passes between a kernel release and a grsec patch release, if any. What if new kernel exploits are discovered, I would be stuck using an old 2.6 kernel just to keep grsecurity, but that would not make much sense because that kernel isn't anymore that secure, so it would perhaps be more secure to get the newest kernel without (sigh) grsec...

you're assuming that the 2.6 series is 'secure', as in, people expert at auditing software for security bugs have combed through 2.6 and found it bug-free. nothing like that happened so far and unlikely it will anytime soon. 2.6 has a ~10MB/month incoming patch rate, you can make a safe bet that the number of exploitable bug fixes in that stream is non-0, has been for the past year and will be for at least another year. yes that means that every single 2.6 release had exploitable kernel bugs in it, whether it was made public or not (or whether anyone was aware of that a particular bug was exploitable, think of last year's do_brk() bugfix). if local security is important for your use case, 2.6 is the worst choice.

Is it the dev's choice to snob the 2.6 kernel, or are there any difficulties writing the patch for that branch?

i can speak of PaX only and yes, there're quite a few changes that interfere with it, and judging from lkml and -mm, there will be more in the future.

thanks for your reply

Not that it will work all the time, but in some cases, you can manually apply an older patch to a newer kernel (especially good chance if its only one release behind) with little or no modifications. You dont know til you try and look at the *.rej files from the patch. Many times I have noticed that the code would still apply fine, but simply couldnt find the proper spot to apply the patch because of the changes made to the kernel. I think you should take a chance next time on a test kernel and try it out, you might be surprised on how often you can do it yourself without relying on poor Brad to be on 24/7 security patrol for ya

Also, use your judgement. If a rej file looks like the function is totally incompatible, then you very well might have to wait unless you feel like kernel panic's.