Rick Welykochy wrote:
Matthew Hannigan wrote:
On Mon, May 23, 2005 at 07:02:24PM +1000, Rick Welykochy wrote:
Matthew Hannigan wrote:
If you did 'yum update ' regularly (every day, at the very least))
you most likely would not have been hit by this exploit.
That is the best way/ path of least pain.
Is it?
In a production environment?
My short answer would be *especially* in a production
environment, if production means 'being exposed to the internet'.
A fuller answer depends what you perceive the risks
are and what other steps you took to protect yourself.
If you're running an integrity checker, selinux, chrooted
apache, no-exec stack, some lesser known architecture, blah blah blah,
you could afford to give yourself a little more time to try out
updates on a test/qa server for compatibility first.
Were you thinking of compatibility concerns or security of
vendor updates? If the latter, well, you either trust them
or not really. Fedora/Redhat gpg sign their updates; you should
enable that checking at least.
Compatibility concerns. The spectre of a security update
introducing more insecurity is rare in my experience.
But updates have screwed things up: RH and libc(?) probs years ago,
Indeed, Red Hat 7.1 moved from glibc 2 to 2.1 mid release. It was
probably Red Hat's worst hour, and since then - 7.2, 7.3, 8, 9, EL3,
EL4, FC1, FC3, and FC3 - they've not changed a major underlying
component in a way that could affect application compatibility mid-release.
In fact, RH go to a great deal of effort these days to make sure hat
doesn't happen. Apache HTTPd on RH 8 suffered from a security problem
that the httpd developers only fixed in a new release, which broke
compatibility with existing pre-built modules. RH have a lot of
customers who add their own module packages - the security fix was
backported to the ver shipped in RH 8. I'm sure RH and FC users on SLUG
could provide copious other examples.
I contract at Red Hat. This is obviously a personal opinion.
Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
