Weekly Edition
Return to the Security pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Security updates for old Red Hat releases
Sites which have deployed Red Hat Linux have a
difficult choice ahead of them. In the near future, Red Hat will cease
providing security updates for these releases. If you have a Red Hat Linux
system exposed to the net, you should be thinking about how you will keep
it secure once the official updates stop coming. There are a number of
choices available, none of which is perfect:
Red Hat Linux users are lucky; users of a proprietary system would not have such a wealth of choices available to them. Even so, these users can be forgiven for occasionally wishing that a "go on as if nothing had changed" option existed as well. That could yet happen. The Fedora Legacy Project is forming with the goal of supporting Red Hat Linux and Fedora Core releases past their official end of life. This project is still in its organizational stages (the inevitable press release is still in draft form) but its volunteers intend to start producing security updates for (at least) Red Hat Linux 7.3 by the beginning of 2004, when support for that release ends. Whether support for the 8.0 release will be offered remains unclear; it depends on whether volunteers show up to produce the updates. There are plans to support Red Hat Linux 9, however. Continuing to use a deployed Red Hat Linux system with the expectation that the Fedora Legacy Project will supply security updates is a bit of a risky option. The project is new and still organizing; there is no way to know whether it will put together the necessary mass of sufficiently talented and motivated engineers to produce reliable security updates in a timely manner. There is no doubt that a volunteer project can perform this sort of task with high-quality results, however, and there should be enough deployed Red Hat Linux systems to motivate a large pool of potential contributors. (Log in to post comments)
What will happen to Kickstart? Posted Nov 20, 2003 5:57 UTC (Thu) by torsten (guest, #4137) [Link] I assist in a lab of RedHat machines. I implemented a Kickstart configuration to bring some of the headless nodes up across the network.I'm wondering if Fedora is intending to continue with the Kickstart program, or should I investigate other tools?
What will happen to Kickstart? Posted Nov 20, 2003 13:56 UTC (Thu) by skvidal (subscriber, #3094) [Link] kickstart is part of anaconda, anaconda is the same in fedora core as it is in RHEL.kickstart is very much IN fedora core.
Security updates for old Red Hat releases Posted Nov 20, 2003 10:20 UTC (Thu) by simlo (subscriber, #10866) [Link] I am right now using RedHat on all my machines. I have an old rh6.2 running sshd and Apache/PHP exposed to the open net. I have to update manually from source now. That is a pain - especially since the last version of openssh didn't even compile on it!So I am seriously considering changing to Debian since I got the impression that updates will always be available. For how long can you keep updating a Debian machine without having to bring it down and reinstall it? If you ignore kernel updates, for how long can you keep updating without even rebooting? (The one machine I am interested in particularly is the old rh6.2 one. It is 300 km away (3½ hours by trains and bus) and I haven't even been at the site for 2 years. It is only rebooted when there is a powercut in the building which seems to happen once a year approximately.)
Security updates for old Red Hat releases Posted Nov 20, 2003 11:58 UTC (Thu) by maceto (guest, #16498) [Link] Eh Debian can run for as long as your hardware goes. you only do apt-get update and apt-get upgrade to get the fixes- then when a new version comes out you do a apt-get dist-upgradeSe you don`t wanna change kernel- use Se-linux or lids then, and lock it down totaly, should help you alot atleast for some time
SE-Linux Posted Nov 20, 2003 12:27 UTC (Thu) by simlo (subscriber, #10866) [Link] > Se you don`t wanna change kernel- use Se-linux or lids thenFrom the very little I know about SE-Linux I still think I can conclude the following: Even with SE-Linux you will have to upgrade the kernel if a bug is found. I can see no way a system can lock down your access if the system itself is buggy (see X-box forinstance). You might live with the bug if it forinstance gives users root permissions as SE then might catch it. But buffer overflows in the kernel itself can still be used to get arbitrary code executed in the kernel thus avoiding SE as well as normal permission checks. And DOS attacks have ofcourse nothing to do with SE or not. On the other hand you can better live with bugs in userspace applications like sshd and Apache as the SE system might be able to catch the problems. Conclusion: Kernel updates are still needed. But you might be able to relax Again, I don't know so much about SE but I don't believe in magic :-)
Security updates for old Red Hat releases Posted Nov 20, 2003 12:11 UTC (Thu) by NAR (subscriber, #1313) [Link] I think you should have had updated to rh7.0, then rh7.1, rh7.2, etc. It is possible, however, this far from the machine it is quite risky. I must admit that it's much easier with Debian to issue an apt-get dist-upgrade, but then you should still reboot if e.g. glibc is upgraded.
Security updates for old Red Hat releases Posted Nov 20, 2003 15:09 UTC (Thu) by smoogen (subscriber, #97) [Link] Debian offers security releases for their releases usually only 6-8 months after the next stable release is done. However since stable releases are a slow process (no matter how many times the leaders want to move it to a once a year) you are pretty good.The one thing to know is that this is all done by volunteers, and if they feel too put upon to release things (too many complaints, not enough help, too much virtual beer and not enough real beer) they have left or changed the release times to better fit their needs. I dont mean this to be a negative on Debian.. I mean it more that freeloaders (people who dont help (either on forums, documentation, patches, testing, etc) and only take) are probably the one thing that hurts it the most..
Security updates for old Red Hat releases Posted Nov 20, 2003 15:52 UTC (Thu) by RobSeace (subscriber, #4435) [Link] I deal with 2 RH6.2 machines regularly, and have a REALLY old RH5.2 machinesitting in the other room from me now... (The latter has currently been up about 124 days...) The "end of life" of these releases isn't really as scary as it might seem... Yes, when a major security hole comes up in something you're running on these machines, you're pretty much on your own to fix it... And, yes, sometimes that can be a real pain... (I certainly wouldn't recommend anyone who isn't a programmer attempt to maintain old releases on their own like this... You often have to get down and dirty with the source, and fix up busted patches, or just code up the fix yourself because no backported patch is available and the new one is too different to apply, etc... It's not for the weak of heart... ;-) But, for a coder, it's not really anything too difficult to cope with...) BUT, thankfully that seems to be a fairly rare occurance... Yes, I've had to patch up sendmail and sshd a couple times... But, that's about it... Over the course of I can't even remember how many years that RH5.2 box has been around... We're talking maybe 1 or 2 issues per year, at the most... No, that's not patching every little thing that comes up; only the stuff that actually MATTERS for your system... Eg: if you don't run sshd, there's no reason to patch it, since it won't impact your security, one way or the other... And, it's also still going with the back-porting approach, in general when possible, rather than upgrading to the latest and greatest spiffy new versions... There are many many cases where you'll see a series of repeated frequent bug reports which only impact the newest version, due to some new feature they added or some code rewrite they did, or something... With an older version, it's generally more stable and proven, and you're probably best off not trying to upgrade until you upgrade the entire system... (Of course, as with everything, there ARE exceptions to this rule...) But, in my experience, on this old EOL'd systems, there really aren't a constant flux of holes you need to keep busy patching every single day, or anything... Things do come up sometimes, but they seem fairly rare to me... *shrug*
Security updates for old Red Hat releases Posted Nov 28, 2003 1:31 UTC (Fri) by mpaananen (guest, #17273) [Link] Well, RH6.2 never shipped with sshd from Redhat, so you were on your own right from the start.
Security updates for old Red Hat releases Posted Nov 20, 2003 17:40 UTC (Thu) by Felix.Braun (subscriber, #3032) [Link] Actually, trusting Fedora Legacy is a sub-option to maintaining security updates in-house. This shows one of the true strengths of open source software: it empowers users and lets them work together efficiently.Thus, there will always be support for any kind of given software as long as there are enough users out there who care. If enough shops decide to contribute a little time to backport security patches, all of them can share the work of the others under the umbrella of the Fedora Legacy Project. Moreover, this support will be the better the more people are interested in it: Many eyeballs make all bugs shallow. Of course, as a corollary this implies that if you are the only one who cares about maintaining a product, you are pretty much left out in the cold unless you can find somebody to pay to do the work for you.
Security updates for old Red Hat releases Posted Nov 21, 2003 22:15 UTC (Fri) by d.e.cox (subscriber, #3912) [Link] Another option is to rebuild RHEL from source, pull the trademarked bits out and get a redistributable OS. From this base, source tracking RedHat's security patches should be fairly easy. And if you don't want to spin it up in-house check out White Box Linux http://www.whiteboxlinux.org/, and the cAos project's soon-to-be-released cAos-el distro, www.caosity.org Both of which are following this route.
|
|||||||||||