LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

View Poll Results: How often do you upgrade your kernel?
Once a month 5 14.71%
Once a quarter 13 38.24%
Once a year 9 26.47%
More than once a month 7 20.59%
Voters: 34. You may not vote on this poll

Reply
 
Search this Thread
Old 12-01-2009, 03:51 PM   #16
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled

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.
 
Old 12-01-2009, 03:53 PM   #17
DragonSlayer48DX
Registered User
 
Registered: Dec 2006
Posts: 1,454
Blog Entries: 1

Rep: Reputation: 74
Quote:
Originally Posted by unSpawn View Post
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.
 
Old 12-01-2009, 11:07 PM   #18
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
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.
 
1 members found this post helpful.
Old 12-02-2009, 10:24 AM   #19
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,991
Blog Entries: 54

Rep: Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743
Quote:
Originally Posted by dragonslayer48dx View Post
Perhaps I misunderstood the question?
As we're strictly taking kernel here I think you might have?
 
Old 12-02-2009, 11:31 AM   #20
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,991
Blog Entries: 54

Rep: Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743
Quote:
Originally Posted by unixfool View Post
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.)
 
Old 12-02-2009, 03:27 PM   #21
nick_th_fury
Member
 
Registered: Jun 2003
Location: Texas
Distribution: Slackware, NetBSD
Posts: 150

Rep: Reputation: 18
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.
 
Old 12-02-2009, 04:38 PM   #22
DragonSlayer48DX
Registered User
 
Registered: Dec 2006
Posts: 1,454
Blog Entries: 1

Rep: Reputation: 74
Quote:
Originally Posted by unSpawn View Post
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
 
Old 12-03-2009, 05:22 AM   #23
edenCC
Member
 
Registered: May 2006
Location: Gz,China
Distribution: RH,FB
Posts: 196
Blog Entries: 1

Rep: Reputation: 32
I chose a quarter, unless there're some critical security/bug fix.
 
Old 12-03-2009, 06:42 AM   #24
Olaus
Member
 
Registered: Apr 2006
Location: Sweden
Distribution: Slackware64 14.1 multilib
Posts: 112

Rep: Reputation: 16
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.
 
Old 12-03-2009, 10:37 AM   #25
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by Olaus View Post
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.
 
Old 12-03-2009, 11:10 AM   #26
Olaus
Member
 
Registered: Apr 2006
Location: Sweden
Distribution: Slackware64 14.1 multilib
Posts: 112

Rep: Reputation: 16
Quote:
Originally Posted by unixfool View Post
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
 
  


Reply

Tags
kernel, security, upgrade


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel Audit Support Unavaible error when booting after kernel upgrade abefroman Red Hat 2 03-21-2013 08:32 AM
can i upgrade the red hat EL4 ES kernel to AS Kernel without upgrading the whole OS? oreaba Linux - Newbie 6 08-19-2008 02:08 PM
apt-get upgrade does not upgrade my kernel halfpower Debian 5 12-11-2005 09:53 AM
What first upgrade kernel or upgrade slack 10.0 to current Kelean Slackware 7 01-16-2005 06:54 PM


All times are GMT -5. The time now is 04:21 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration