Quote:
Originally posted by Phil21
Upgrading the kernel every time a new release comes around IMO is stupid and unneccessary.
Unless there are documented (even in theory) problems with kernel code, it's nigh on insanely improbable that there is a remote attack available. (If you have local users you don't trust, or give out FTP accounts, etc. - anything that users have system level access to, I would be more paranoid here).
Upgrading like that will over time cause you more problems than it fixes. Our policy is to wait 3-5 weeks after a kernel is released, and note any new bugs that surface that may impact us. We also note any improvements made to the kernel, and upgrade as we see fit there.
That said, we usually are running the latest kernel on most machines 2-3 months after release. We usually schedule kernel upgrades w/ other maintaince windows and systems get rebooted when otherwise unavailable anyways.
And yes, I would fully agree that misconfiguration/inexperience is by far and away the #1 reason systems are penetrable. By default our dedicated machines come with only apache, ftpd, and sshd installed as services, so a customer would have to actively do something to change that. No matter what we do though, we can't protect people from themselves. No matter how many times we explain permissions, or why folks should learn unix security basics before opening that file provided in user input with PHP, people still insist on "knowing better".
-Phil
|
I strongly disagree with you in this. Kernels are released for a reason, and each major kernel release fixes many problems - although maybe not as severe as remotely exploitable or locally root exploitable, it can greatly increase a hacker's chance of combining it with something else to achieve their goal.
Causing more problems than they fix? The kernels don't change their entire specs with new versions, they syscalls DO in fact stay the same. You just have to know what you're doing when compiling it to ensure you include all the modules etc. that you require - any competent system admin would have no trouble with this what-so-ever - it's one of the most fundamental Linux security tasks.
As for testing a new kernel, if you frequented kernel.org or were current with the way the kernel upgrading works, you would realise that they don't just hit you with a brand new release. They have rc candidates for months before hand that are tested by thousands of people (including RedHat, Debian, all the popular distributions). This has been the case for as long as I can remember which is why you can be confident in installing a stable final release.
It is an extremely rare occurence that the kernel itself will cause more problems than it fixes over the previous kernel, unless human error and/or stupidity with upgrading the kernel comes into effect.