...I immediately upgrade my kernel to the latest release with the fix.
9% (202 votes)
...I check if the issue affects me, and if so I immediately upgrade.
38% (842 votes)
...I think to myself "maybe I should be patching my kernel".
17% (379 votes)
...I try and understand how the exploit works.
8% (182 votes)
...I laugh because it doesn't affect my favorite OS.
7% (146 votes)
...I wonder if those kernel developers really know what they're doing.
5% (104 votes)
...I'm impressed with how thorough those kernel developers are.
4% (90 votes)
...I go looking for more interesting news.
12% (254 votes)
Total votes: 2199
multipal options
This isn't really that fair. Often I do several of those things. normally, I try to understand the vulnerability. and if it affects me. I will then immediatly upgrade if it does. Or, perhaps I will just think about upgrading.
jacks4u
Hear, hear.
Local privlege exploits don't matter overmuch to my developement and desktop machines, but the server I maintain for friends and family is another story.
And what about those who rely (due to either company policy or inexperience) on vendor kernels? Why not include "Contact the vendor I pay to keep me abreast of these things"?
Local problems need fixing too
Local privilege exploits are just as dangerous as remote ones. You only need to get an unfixed unprivileged remote exploit and the local one becomes enough to take over the system. It's only if the problem is in code that you don't have on your system that it's safe to ignore it.
The first thing I do is to ge
The first thing I do is to get a copy of the exploit and then run it in my test box to see if it actually works. Usually all the kernel patches I use block the exploits. In any case, I patch the current kernel and if the exploit works, I reboot immediately. If the exploit doesn't work, the patch will be effective after the next reboot even if it wasn't necessary.
Fortunately our server base is diverse enough, so problem with one OS doesn't require me to upgrade every single machine :)
Fortunately our server base i
Fortunately our server base is diverse enough, so problem with one OS doesn't require me to upgrade every single machine :)
I hope that's a joke. Wildly different server types are a PITA to admin. Just think it through - one single server build (engineered..) means the steps you describe need doing once, and can be done on a test server. "Diverse server base" means all those steps need doing as many times as you have types of server, and you can't run it on a test server, you have to test the exploit on the server itself. Limiting server builds and patch revisions to a minimum is basic best practice for your admins.
Hardened Gentoo :)
I use the Hardened Gentoo sources, which patch the kernel with all the latest security fixes. The hardened-dev-sources (2.6 branch) have a new release almost every day though. Kind of shows how well the 2.6 development model is working for security, huh? *cough*
Seriously, I just stay up to date on h-d-s. If they don't have a patch, I assume there isn't one. That's why it's important to always use a patchset and NOT a vanilla kernel; most kernel patchsets like CK, -ac, or Hardened Gentoo's, even Gentoo's basic gentoo-dev-sources (2.6) and gentoo-sources (2.4) will always have security fixes.
When you're on a production server, you can't take this. Local exploits become serious for a multiuser environment; and you become a target for attacks if your server is well known. A secure environment is NEEDED.
I gave a Blog entry about hardened-dev-sources-2.6.10 when it was about to come out. A few days later, -r2 was already out with even more fixes; that entry's about h-d-s-2.6.10.
I also blogged about why the current kernel development model needs to be changed, with some suggestions on how to alter it slightly to produce a more production-ready development model. Later I updated that with greater justification and a suggestion to add an audit cycle to my proposed model. None of this is being considered upstream of course.
I guess nobody is going to take steps to provide a more secure and production ready vanilla series. It's really saddening to think about it; I blame most of the problem on the way the 2.6 development model is applied. It's an excellent model, but it needs to be for a development series.
One problem is that nobody te
One problem is that nobody tests mere development releases, so they are forced to pretend they have a new stable release. ;-)
If one wants a 'truly' stable kernel, one should be using a kernel from a distribution is the idea, as you underlined.
I agree, it is far from perfect. But the point is, the development of the Linux kernel is of primary importance, and the current model is extremely productive. Why fix it if it aint broke? Additionally, the unstableness of 2.6 can be quite relativated.
2.6 model & security
> Kind of shows how well the 2.6 development model is working for
> security, huh? *cough*
In fact it does. It shows that with the current 2.6 development model security (and other) bugs are actually being found and fixed.
To actually meassure if the new model works well you'd need to analyze how many of the bugs fixed are in old code and how many are in newly added code - I think you'll find that most of them are being found in old code and have actually been present for ages, but have just been discovered and fixed now.
2.6 is stable???
Either kernel is stable, or it is not.
Right bow, 2.6 obviously is _not_very_stable_ ...
'Stable'
Please define stable.
Are we talking about feature stablility (no new features - i.e. Debian stable), or: no big horrible bugs/long uptimes on lots of hardware, or some other definition of stable?
-- Run.exe
you should have included an "
you should have included an "I use OpenBSD" option
I use ms-windows
I laugh whenever i see this as i use a modern and secure system
called ms-windows...
It filled with friendly virus and bugs that new ones can't find a place to survive in this zoo.
Its like the stomach...filled with friendly bugs that keep the bad bugs out !
>>It filled with friendly vir
it more of a jungle , lol !
hehehehe, you must try the mo
hehehehe, you must try the most modern version, XP, "XPlode itself"... or the most stable version... Windows ME... hehehehehe
Patched kernel in distribution
I wait for a patched kernel in distribution (Debian GNU/Linux Sarge). I'm still waiting for a patched 2.6.8.1 kernel with a revision which includes the latest 5 security patches. I'm not happy with this this!
Sarge does not get security updates
That is because Sarge does not do Security updates
(please read their site), either go back to woody or monitor Unstable..
*hlfs*
http://lfs.osuosl.org/hlfs/view/unstable/
--
Testing needed before cut-over
People who have fleets of computers that are used for things other
than word processing and web surfing can't just cut over from one
kernel to another based upon a security threat.
Security is important, yes, but service provision is king. If you
have toyed with OS internals before, you certainly know that
upgrading your kernel tends to break things - usually in unexpected
ways.
That's why it is necessary to test all modifications that are
planned for a production environment first in a testing or
development environment.
So, "immediately upgrading the kernel to the latest release with the
fix" might not be a very profitable notion. It's fine, I suppose,
if your computers aren't doing anything productive anyhow, but how
many people do you know that go out and spend thousands or millions
on computers that just sit around doing nothing?