rs wrote:What's the recommended kernel branch from a security standpoint: 2.4 or 2.6? I remember having read somebody (officially?) recommending 2.4 over 2.6? Is it still true, Brad?
not Brad speaking
, but it's still true, we recommend 2.4 although reality more and more often doesn't really leave you that choice (lack of hw support or some kernel features your desired userland wants).
What's the current policy about grsec releases? While kernel.org publishes new kernels often, not all are instantly "supported" by grsec, until Spender reviews and releases a new patch, which, I guess, depends on changes implemented in new kernel (for instance, whether or not the new kernel has an important security fix). Right?
for the 2.6 series the bottleneck wasn't grsec per se but rather PaX that the kernel powers that be managed to break for pretty much every single release, so it takes time to forward port PaX and have something that at least boots
. nevertheless, the policy is that we try to stay close to the last 'stable' 2.6.x, and we don't support nor backport anything to previous 2.6.y kernels. security fixes in 2.6.x.y are normally followed up quickly because they tend to break a lot less if anything at all (often you can just take the previous grsec patch and apply it without a problem).
Is safe to assume that latest grsec patches corresponds to safe kernel releases? For instance, latest grsec patches relates to kerneles 2.4.34/2.6.19.2. Would it be safe to continue having 2.4.34, despite 2.4.34.1 being the latest? (or having 2.6.19.2 over 2.6.20.2?)
you should always use the last vanilla kernel because it most likely has security fixes that are not in grsec per se. you can either wait for spender to release a new grsec for 2.[46].x.y or try to apply the previous one yourself, it mostly works.