Weekly Edition
Return to the Security page
| |||||||||||||
|
| |||||||||||||
Risk report: Three years of Red Hat Enterprise Linux 4
Red Hat has published an updated version of its risk report for RHEL4, summarizing the security vulnerabilities in that distribution for the last three years and how Red Hat responded to them. "Fixes for 81% of critical flaws were available from Red Hat Network at latest one calendar day after public disclosure of the flaw. 63% of the critical flaws were fixed on the very same day. This fast response time is a deliberate goal of the Red Hat Security Response Team and forms an
essential part of reducing customer risk from critical flaws." It would be nice if all distributors would produce an occasional report like this.
(Log in to post comments)
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 8:09 UTC (Wed) by BackSeat (subscriber, #1886) [Link] Whilst this is admirable, and I agree that it would be nice if all distributors would produce an occasional report like this, Red Hat's job is made somewhat easier than, say, Debian's due the number of packages in the distribution. Last time I looked, RHEL had around 1,800 packages in total and Debian had in excess of 18,000. (I've tried recently to find a list of packages supported by RHEL but without success: am I the only one that finds Red Hat's website almost impenetrable?).
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 9:08 UTC (Wed) by bangert (subscriber, #28342) [Link] and the number of architectures supported by the product. gentoo has eight security supported architectures (IIRC).
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 16:18 UTC (Wed) by dowdle (subscriber, #659) [Link] Exactly. Now you know WHY Red Hat reduced the number of packages and has a smaller number of arches... to make their product more supportable... easier to support... however you want to put it. On the other hand, the project they sponsor (Fedora) appears to be growing towards Debian size with regards to package number... but it has a ways to go.
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 29, 2008 23:24 UTC (Fri) by Tet (subscriber, #5433) [Link] While it's true that Gentoo's 8 supported architectures is a lot, the last time I looked, RHEL supported 5, so it's not as if they only have a single architecture to worry about...
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 9:21 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] Red Hat has to commercially support everything it ships. http://www.redhat.com/support/policy/sla/production/ That makes it prudent for Red Hat not to commit itself to do that at the enterprise level for many software components unless there is a serious commercial demand for it. Rest of them can take advantage of EPEL http://fedoraproject.org/wiki/EPEL It is a relatively recent project but already has over 2000 software packages available for EPEL 5.
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 13:31 UTC (Wed) by TxtEdMacs (subscriber, #5983) [Link] Odd, but I never thought Debian or any non-commercial version could be expected to produce such a report. Isn't the point here that distributions that charge for commercial support, i.e. providing fixes for software flaws view this as another part of their message? So what entities should be compiling such statistics? Well, certainly Red Hat, Novell's SuSE and eventually Ubuntu. The latter, if its server version takes off. And in the bigger scheme, Sun could do the same. [With regard to CentOS, they should easily produce their copy by merely taking the Red Hat's report and adding a delay factor implicit in getting fixes up on their site. Hence, some will have an easier time than others.]
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 28, 2008 9:30 UTC (Thu) by mjcox@redhat.com (subscriber, #31775) [Link] There are lists of packages in a default install available already (cpe lists) at: http://www.redhat.com/security/data/metrics/ But they're not the full package lists. I do intend to eventually add some of the full package lists for given combinations of rhel versions over time and where useful for stats.
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 8:53 UTC (Wed) by DG (subscriber, #16978) [Link] It's great RedHat are so open about such things - I often wonder how other distros compare, it would be great if they all published comparable statistics. Perhaps it's a case of 'You get what you pay for'?
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 12:30 UTC (Wed) by emk (subscriber, #1128) [Link] Another data point for you: At work, I manage a mixed network of Debian stable and Ubuntu 7.10 servers. The Debian security team generally issues updates several days before Ubuntu, and they cover the entire distro, not just a small, supported core. As I otherwise prefer Ubuntu (because they release updates twice a year), this is rather disappointing to me. But kudos to the Debian team!
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 27, 2008 22:46 UTC (Wed) by drag (subscriber, #31333) [Link] > because they release updates twice a year I follow Debian Lenny/Sid on my stuff and I get updates all year long. :) 2.4.26 kernel, Gnome 2.20, xorg 7.3 and all that happy stuff. The trick is, for me at least, to enable both lenny and sid in my sources.list then use apt_preferences to set the priority for Lenny. Then I install stuff from sid when I feel like it..
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Feb 28, 2008 10:51 UTC (Thu) by errare_est (guest, #14275) [Link] I do run debian/(unstable|sid) on my workstation, but having that on a production server is too risky: I love my weekends.
Risk report: Three years of Red Hat Enterprise Linux 4 Posted Mar 1, 2008 1:02 UTC (Sat) by jordanb (subscriber, #45668) [Link] Debian Testing doesn't seem to me to any more risky than Ubuntu Stable. If you want incredibly carefully built and tested release, you need to go with Debian Stable. If you want quick releases, then, well, modulus Canonical's advertising, there's some risk in that.
Risk report: Not only numbers count Posted Feb 27, 2008 11:09 UTC (Wed) by chel (guest, #11544) [Link] Although it is a good track record and numbers are quite manageable, I don't think it is a good idea in general to express system security in these kind of manageable numbers. Remember the Titanic had two flaws: wrong steel and insufficient lifeboats.
Risk report: Not only numbers count Posted Feb 27, 2008 13:34 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Hmm, I'm sure we can come up with a pretty huge number of problems even just relating to that one incident. * Improper lifeboat training for crew (and none at all for passengers) meant that most boats were sent away half-empty. Almost twice as many people could have survived if every boat had been filled. With this problem even if Titanic had carried "sufficient" boats many would have drowned. * Lack of engineering experience with huge ships meant that the rudder was inadequately sized. Hence Titanic could not turn quickly to avoid the iceberg as other ships would have in the same circumstances. * Cost and weight considerations meant Titanic did not have full-height bulkheads. A smaller ship owned by the same company had remained seaworthy after losing the entire bow of the ship, full-height bulkheads prevented water from flooding the remainder of the vessel. * Lack of communications standards meant that the sailor on watch who saw distress flares go up from Titanic dismissed them as celebrations. * Poor navigational fixes meant that Titanic's position was mis-reported, delaying rescue for those who didn't drown and thus causing further loss of life.
Risk report: Not only numbers count Posted Feb 27, 2008 14:46 UTC (Wed) by chel (guest, #11544) [Link] Well, I hope the message is clear. For flaws the number isn't as important as the impact. If you fix a flaw only minutes after it causes a meltdown of a nuclear plant, it is still too late. Many of those manager oriented statistics have limited value in real life. It are numbers, but calculus can and should not be applied with those numbers. To take an example, for a car, failing brakes are a real problem, if one of the two light bulbs in a rear light is broken it is not. You should not add up the two to draw a conclusion. If you do you may end driving a car with only one flaw: no brakes. BTW I have no problems with RH product quality. Over 10 years ago I started to use RH products in mission critical applications.
Risk report: Not only numbers count Posted Feb 27, 2008 21:17 UTC (Wed) by proski (subscriber, #104) [Link] A single flaw would not normally cause anything as bad as a reactor meltdown. Systems where safety and security are paramount are designed in such way that a single flaw doesn't cause a complete failure. For instance, firewall protects against outside access, services require authentication to keep strangers away, there is a strict separation between users and root, the system is monitored, the essential data is stored on a separate system and there are offsite backups.In the real life, there are things other than complete success and total failure. Even on Titanic, there were survivors. Security experts are more categoric when it comes to vulnerabilities in individual packages because it's better be safe than sorry. Yet it's entirely justified for a distribution to post general statistic. It's a measure of how diligent the distribution has been at fixing issues in the packages it ships. It can be translated to security of individual systems, but it's not a trivial dependency.
Risk report: Not only numbers count Posted Feb 27, 2008 22:12 UTC (Wed) by chel (guest, #11544) [Link] I suggest http://www.securityfocus.com/news/8412 for further reading, especially the part about the race condition bug that blinded the control system, and played a major role in the NE Blackout. For me Open Source design together with bug finding projects on several places is much more important then fixing time of bugs after they have been published. Not every bug is published before a disaster. For the NE blackout: "About eight weeks after the blackout, the bug was unmasked as a particularly subtle incarnation of a common programming error" The best place and time to find and correct bugs is on your desk before damage is visible. OSS helps to do that. My problem with this kind of statistics is that it moves the discussion in the direction of discussions about OS-es that fix flaws in virus checkers.
Risk report: Not only numbers count Posted Feb 27, 2008 18:10 UTC (Wed) by tzafrir (subscriber, #11501) [Link] Have you read the full article before posting that? I found that article and the previous "Risk reports" an interesting reading. Even though I normally use a different distro.
|
|
||||||||||||