LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   How often do you upgrade your kernel? (https://www.linuxquestions.org/questions/linux-security-4/how-often-do-you-upgrade-your-kernel-770112/)

anomie 12-01-2009 03:51 PM

I'm really not defending an infrequent kernel update policy. The way it goes here is: no tolerance for breakage on certain server systems. Kernel updates are evaluated case-by-case, and if a vulnerability is insidious enough, I can usually make a strong case for updating.

It is far from ideal, but we work on other ways to mitigate the risk.

DragonSlayer48DX 12-01-2009 03:53 PM

Quote:

Originally Posted by unSpawn (Post 3776041)
Indeed business agreements dictate different upgrade routines but for a net-facing SOHO machine to only receive updates on a yearly basis or more just does not seem right IMHO. For me personally it's within 24 hours of time of update for (almost all) machines.

Perhaps I misunderstood the question? I update immediately whenever the distro maintainers make it available. I just don't manually upgrade to newer versions.

unixfool 12-01-2009 11:07 PM

In everything related to IT (and life), there's such a thing called mitigation. If you can't update (and the reasons may well vary), you evaluate the risk of updating (or not updating) based on the changes that need to be applied. You then make decisions based on the results of the evaluation. You can't always have it your way or the next individual's way. Each and every admin has to decide whether they can patch or not based on all the above, plus supervisor input and change management procedures. If you know that there's serious risk, argue to do the patching. If you can't perform the patching, mitigate the risk (harden against any discovered vulnerabilities. I really don't think (and this is my own professional opinion) you should blindly push every kernel major change/addition/removal without a proper evaluation of how it would affect a business (or a SOHO but critical system).

Do I have the very latest BIOS update for all of my systems? NO! I only update the BIOS if I need a particular feature/issue that the later version may address. Kernel updates aren't quite the same as MS Tuesay notifications. Most local kernel level exploits can be mitigated. You just need to be able to trust that your hardening is hard enough to keep unwanted people out of the systems.

I know of several critical Linux systems at my workplace that don't have the latest/greatest kernel. These systems are behind at least 5-6 hardware firewalls/IPSs, each system has its own software FW, ACLs are tighter than a python's knot, and they've been running for years. Is it right that they aren't semi-current? No, but again, the risks are mitigated. These boxes don't even go outbound to the internet...every connection is established via PTP VPN. When people know what they're doing, mitigation works.

It's a different approach but it works. Every system that I have control of, I try to make it as close to a bastion host as possible...that's the way it should be, IMO.

All of this is up for interpretation. There is no real standard and there shouldn't be. There is no right way (and there shouldn't be). If we become so rigid in addressing security, we only make it that much easier for crackers to do the things they do.

So, if your boss rejects updating a box's kernel, do you argue until you're fired? IMO, you do what you're hired to do, take direction from your boss (and cover your tracks), then let the boss take the fall if it comes to that. For SOHO environment where you're in charge, do it sensibly. If sensibly means postponing, then postpone (and mitigate the risk)! If one of your machines becomes compromised, learn from the experience, clean up the mess properly, then move on.

unSpawn 12-02-2009 10:24 AM

Quote:

Originally Posted by dragonslayer48dx (Post 3776175)
Perhaps I misunderstood the question?

As we're strictly taking kernel here I think you might have?

unSpawn 12-02-2009 11:31 AM

Quote:

Originally Posted by unixfool (Post 3776551)
In everything related to IT (and life), there's such a thing called mitigation. If you can't update (and the reasons may well vary), you evaluate the risk of updating (or not updating) based on the changes that need to be applied. You then make decisions based on the results of the evaluation. You can't always have it your way or the next individual's way. Each and every admin has to decide whether they can patch or not based on all the above, plus supervisor input and change management procedures. If you know that there's serious risk, argue to do the patching. If you can't perform the patching, mitigate the risk (harden against any discovered vulnerabilities. I really don't think (and this is my own professional opinion) you should blindly push every kernel major change/addition/removal without a proper evaluation of how it would affect a business (or a SOHO but critical system).

Not all kernel security updates address are required for every server so on the business side of things one needs careful assessment too. Also there's clients that pay for taking care of things and some that don't (pay easily, I mean). Meaning lots of risk management and discussion is involved to be able to even push updates. Even testing on staging might not reveal every risk in updating (servers showing a tendency to b0rk on reboot and always mysteriously) and multiple data centers doesn't mitigate things either (a client DoSsing his own infrastructure sounds nice except for the service manager and admin team being asked to fix things 3 in the morning). I know there is a part of the LQ Community that is (by experience) aware of what requirements need to be satisfied on the business side of things and I too have experienced it can't be any other but that way. But for the SOHO side of things it is and should remain "update as updates are released" IMO. (I mean, just in case anyone think they can misread all of this as their cue to slack off.)

nick_th_fury 12-02-2009 03:27 PM

At home I used to do it every release till I really got the hang of it. It was kinda fun playing with the options & learning. Now I only do it when my distro upgrades to a new stable version or if there is a security update that directly effects my setup. The production machines at my work we only update for security reasons.

DragonSlayer48DX 12-02-2009 04:38 PM

Quote:

Originally Posted by unSpawn (Post 3777222)
As we're strictly taking kernel here I think you might have?

OK, the original question was, "How often do you upgrade your kernel?"

Perhaps I was wrong, but I considered that to mean upgrading to a newer version. That I only do with my distro upgrade.

Updates (patches for the current version I'm using) are offered quite frequently. Those are installed ASAP.

Cheers

edenCC 12-03-2009 05:22 AM

I chose a quarter, unless there're some critical security/bug fix.

Olaus 12-03-2009 06:42 AM

Whenever there is a new version
 
Since the only thing you have to do (most of the time) is
make mrproper && cp oldconfig .config && make silentoldconfig
and since I also have made a script that takes care of the installing (including nvidia drivers), it is really a piece of cake to do the upgrading as often as possible.

unixfool 12-03-2009 10:37 AM

Quote:

Originally Posted by Olaus (Post 3778272)
Since the only thing you have to do (most of the time) is make mrproper && cp oldconfig .config && make silentoldconfig
and since I also have made a script that takes care of the installing (including nvidia drivers), it is really a piece of cake to do the upgrading as often as possible.

The key words are, "most of the time". I'd rather not have to deal with the "what ifs" when scripting, even with such a simple combined command as that, as I know someone will eventually expound on such a suggestion to wget a kernel, unpack it, have the script crunch it and apply it, then create a cronjob for it, somehow. I'm a firm believer in keeping the human factor within everything I do. This is why I hate IPS technology and is why I still run Slackware. It's when things get broken that people begin to second-guess themselves. I'd much rather apply the hands-on approach.

That's just me, though.

Olaus 12-03-2009 11:10 AM

Quote:

Originally Posted by unixfool (Post 3778554)
The key words are, "most of the time".

Of course I have to deal with the results of 'make silentoldconfig', should there be any new features in the new version, but besides that, it has so far worked flawlessly. The scripts cannot run unattended, but you don't have to do anything more than just look at the result if there are no new features. I also edit lilo.conf manually.
The install script, which is called with the kernel version as argument: (I use two Nvidia variables, should I want to upgrade the nvidia module at the same time)
Code:

#!/bin/bash
NVIDIA=/root/NVIDIA-Linux-x86-190.42-pkg1.run
NVIDIA_OLD=/root/NVIDIA-Linux-x86-190.42-pkg1.run
VER=$1
SRC_DIR=/usr/src/linux-$VER
if [ -d $SRC_DIR ]; then # does the source code directory exist?
$NVIDIA_OLD --uninstall -s #remove nvidia driver from current kernel
cd $SRC_DIR
make modules_install
cp $SRC_DIR/.config /boot/config-$VER
cp $SRC_DIR/System.map /boot/System.map-$VER
ln -sf /boot/System.map-$VER /boot/System.map
cp $SRC_DIR/arch/i386/boot/bzImage /boot/vmlinuz-$VER
$NVIDIA -s -k $VER #install nvidia driver in new kernel
fi



All times are GMT -5. The time now is 05:37 PM.