Post #186,351
12/7/04 8:38:21 PM
|
Need help shutting up a Windows bigot and a RedHat bigot
If you got bored with the saga of my non-functional keyboard, let me summarize: I moved the box to a new desk yesterday. It was the first reboot in 196 days. When it came up I had no mouse under X. Turns out it was looking for the ps2 mouse that used to be hooked up, which I had ditched in favor of a usb optical several months ago (but never unhooked the ps2).
Before I figured it out the Windows bigot had already pointed out he never has problems identifying hardware[1], and the RedHat bigot had declared that 196 days of uptime is a sure sign I've missed kernel-hack security updates.
I don't really care about the Windows hardware issue, as our Windows boxes flaking out have cost each of us far more than the couple of hours I was halfway working on this. But the kernel hack issue -- and this is coming from the guy who admins our RedHat webservers -- is bugging me.
First, while I have actually gotten a virus on my Windows box in the last 196 days[2] I haven't had any problems with the Linux box. Potential security hole be damned, nothing actually happened. But the other issue is I could swear I remember there's a way to switch to a new kernel without rebooting. Am I losing my mind? Or am I remembering a project that was trying to do that?
[1] And that his Windows box now has more uptime than my Linux box. Bitch.
[2] With a team of people trying to make sure I don't.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #186,353
12/7/04 8:51:09 PM
|
You know Greg posted it. :-)
[link|http://z.iwethey.org/forums/render/content/show?contentid=154082|#154082]. From the linked article: Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence -- that is, the firmware -- is completely avoided. The big gain from this feature is that system reboots are now extremely fast. For enterprise-class systems, kexec drastically reduces reboot-related system downtime. For kernel and system software developers, kexec helps you quickly reboot your system during development or testing efforts without having to go through the costly firmware stage every time. Have your uptime and change your kernel too! Cheers, Scott.
|
Post #186,359
12/7/04 9:20:41 PM
|
That's probably what I remember
But the kernel has to have it already compiled in, and it's not done yet anyway.
So what is the answer to the charge that uptime == poor security?
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #186,360
12/7/04 9:27:31 PM
|
The kernel is only one piece of the puzzle.
As Yendor said, a good firewall will prevent many attacks.
If your server was booted from a CD and nothing had permission to write to RAM or the hard disk, then an ancient kernel would be pretty secure. ;-)
I don't know what would be a good argument to rebut them, but the converse is clearly not true (i.e. Short Uptime is not a guarantee of Security).
Cheers,
Scott.
|
Post #186,361
12/7/04 9:32:32 PM
|
The answer is to admit you are wrong
Yes, a decent firewall with NO services on your box it pretty safe.
So what?
It is a valid observation to say that running an unpatched kernel with known security holes is a risk. Accept and ignore it, or fix it.
|
Post #186,367
12/7/04 10:22:44 PM
|
Perspective
An unpatched kernel with theoretical holes exploitable with (typically) physical access to the box, vs a fully-patched Windows/Internet Explorer/Outlook setup that is still vulnerable to remote exploit on a near-weekly basis. I'm still way ahead of the Windows guy.
Now let's forget hypothetical and see what I've actually been unknowingly vulnerable to. According to Debian's [link|http://www.debian.org/security/2004/|Security advisories announced in 2004], there has been [link|http://www.debian.org/security/2004/dsa-514|one] known kernel exploit since May of this year. And it was for the 2.2 kernel on Sparc.
So, what was I wrong about? And what should I be admitting to the RedHat bigot with the assload of FUD?
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #186,373
12/7/04 11:17:30 PM
|
Not playing the VS windows game
This has nothing to do with how piss-poor windows is.
Nor does it have to do with physical access. You are on a network.
Are there other computers are on the network? If so, maybe they were cracked 1st so not the firewall won't help you.
Nor am I playing the "known" exploit game.
Kernel programmers found security holes. They fixed them. You didn't apply the fixes. Straight forward.
|
Post #186,391
12/8/04 1:21:23 AM
|
No they didn't
Kernel programmers found security holes. They fixed them. You didn't apply the fixes. Debian practices full disclosure. If there's an update that potentially affects security, it's pushed through a [link|http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s-security-update|separate channel]. Look at '/etc/apt/sources.list' on your Debian box. You should have a line like 'deb [link|http://security.debian.org/|http://security.debian.org/] stable/updates main contrib non-free'. It is possible to configure your system to automatically install all security updates, and each patch will be the mimimum change required to fix the security issue. Unless someone closer to the process than I am wants to contradict or clarify, there were no kernel exploits patched since May of this year that affected me. ===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #186,426
12/8/04 1:09:44 PM
|
Correct. Since before May.
Some of the exploits were for kernels newer than yours. Some of those exploits were removed from Debian before the knowledge of it happened to show, as the affected areas were fixed by Herbert Xu.
The new Kernel Team is doing a seriously Awesome job. Besides Gentoo and Greg KH, Debian is the number one Distro with upstreaming fixes and updates.
-- [link|mailto:greg@gregfolkert.net|greg], [link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwetheyNo matter how much Microsoft supporters whine about how Linux and other operating systems have just as many bugs as their operating systems do, the bottom line is that the serious, gut-wrenching problems happen on Windows, not on Linux, not on Mac OS. -- [link|http://www.eweek.com/article2/0,1759,1622086,00.asp|source]Here is an example: [link|http://www.greymagic.com/security/advisories/gm001-ie/|Executing arbitrary commands without Active Scripting or ActiveX when using Windows]
|
Post #186,378
12/8/04 12:15:27 AM
|
I was running 2.4.20 unpatched
Since the day I compiled it with Stack Smashing Protection patched compiler and Mudflap.
I had 420 days of uptime. I even dared a coupla people to try and smack knight. They tried, I saw the evidence. The worst they could do was to start a daemon run by www-data on a port I don't allow in or out... through the firewall from knight.
Ummm, yeah... kernel-hacks. Most are only if you get a local account/shell. Sure, start a telnet daemon on port 31337. See if you can connect to it. Uh, huh.
-- [link|mailto:greg@gregfolkert.net|greg], [link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwetheyNo matter how much Microsoft supporters whine about how Linux and other operating systems have just as many bugs as their operating systems do, the bottom line is that the serious, gut-wrenching problems happen on Windows, not on Linux, not on Mac OS. -- [link|http://www.eweek.com/article2/0,1759,1622086,00.asp|source]Here is an example: [link|http://www.greymagic.com/security/advisories/gm001-ie/|Executing arbitrary commands without Active Scripting or ActiveX when using Windows]
|
Post #186,354
12/7/04 8:53:58 PM
|
Re: Need help shutting up a Windows bigot and a RedHat bigot
[...]I haven't had any problems with the Linux box. Potential security hole be damned, nothing actually happened. Yes, it is possible that you've missed security updates. I don't follow bugtraq or anything like that, but it's always *possible*. Thing is, though, I haven't updated my kernel (or installed a new one) in I-can't-remember-how-long. My webserver (the one that faces the world) is currently running a stock 2.6.6 kernel, and has a 67-day uptime. Personally, I think that if you're behind a good firewall, that's 90% of the battle right there. If the bad guys can't get directly to your box in the first place, then that's one more layer of boxes that they have to go through. I suppose I'm assuming that all your network-facing boxes in the DMZ are properly secured. (I know, I know, that might be a faulty assumption...But I'm making it anyway.) -YendorMike
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
|
