This article is more than 1 year old
New Linux support policies are ominous
Security nightmare, says Jon Lasser
Open source opponents have for years warned, "You get what you pay for."
Now some Linux distributors are planning to make good on that threat. Red Hat and Mandrake's recently-announced revised support policies might spell the end of the free ride for many companies using Linux.
The policies are straightforward: Red Hat will support their regular distributions for twelve months from initial release. Red Hat's venerable version 6.2 will be retired on March 31st along with version 7.0. Versions 7.1 through 8.0 will expire on December 31st. After the expiration date, security patches will be provided at Red Hat's discretion only.
Mandrake's new policy is similar, though a little more confusing: Mandrake will support "desktop components" of any new distribution for twelve months, and they'll support "base" components, including the kernel and Apache, for eighteen months. Which category the other packages fall into remains to be seen.
Mandrake 7.2 and 8.0's desktop components are immediately unsupported, while their base components will be supported until March 31st. Mandrake will drop support for 8.1, both desktop and base packages, as of March 31st as well. Version 9.0's end-of-life dates are September 30th and March 31st of next year.
How you interpret these announcements depends on what hats you wear: I didn't know whether I should, laugh, cry, or cheer. As a systems administrator, my first reaction was definitely to cry.
Vendor-provided security patches are, unfortunately, the lifeblood of distribution support. Without well-integrated and well-tested patches, maintaining a Unix server takes a lot more work: you have to track every installed package on your system and rebuild necessary subsystems whenever a patch is released.
Though users of commercial Unix distributions have been doing this for years, users attracted to Linux's relative ease of use and maintenance frequently don't have the technical skills to keep up while not falling behind on other important tasks. Without these vendor-provided patches, most Linux users -- and even many professional system administrators -- will have trouble keeping their systems safe.
Twelve or eighteen months is nothing in the life of a production server. In many shops it can take more than six months to certify an application for use. In such an environment the install-test-release cycle would be constant. Furthermore, servers are often hard to update: permissible downtimes may be rare, and co-located servers are even more difficult to handle.
Two Weeks Notice
On the bright side, at least Red Hat and Mandrake have policies that will allow me to plan, or to make other arrangements. I still have a bad taste in my mouth from the Debian 2.1 support debacle. On September 14th, 2000, the Debian project announced that, as of September 30th, support for Debian 2.1 would be dropped entirely.
Two weeks notice is simply not enough time to do even minimal testing before updating a production server doing anything more complicated than serving static Web pages. Furthermore, Debian 2.2 had been released on August 14th -- only one month earlier.
I know that Red Hat and Mandrake have important reasons to limit support for older operating systems: first, open-source software has an unfortunate tendency to live forever -- many users are still relying on versions of Red Hat even older than 6.2, and supporting these primordial distributions is expensive. The QA and build machines need to be supported, and developers must be diverted from more forward-looking tasks. Given that Linux distributors make little money supporting these older releases, dropping patches must seem like a no-brainer from their point of view.
And to their credit, both companies have different rules for "server-class" products: Red Hat will support their Advanced Server for five years, and Mandrake's policy states that server software will be supported for "no less than twenty-four months." Red Hat and Mandrake are clearly banking on support contracts and installations of their advanced server products to generate revenue.
It's not unreasonable to expect people who want commercial quality support to pay for it.
But as an advocate for better computer security, I'm nearly panic-stricken over this move. In the short term, at least, this will be a big negative for practical security on the Internet. Old software doesn't go away just because it's no longer supported, and with network operating systems the consequences could be drastic. Those systems will be sitting ducks for vulnerability scanners, and the size of distributed denial-of-service networks may grow exponentially as a result.
After all, many users have come to rely on the auto-update mechanisms provided by vendors, such as Red Hat's up2date tool. When Red Hat's support for 7.3 goes away, tens of thousands of users will have no automated way to apply third-party security patches to the base OS.
As an open-source advocate, I must say this problem is also an opportunity.
We have a large base of commonly used open source applications, and we now have to develop support mechanisms that do not rely on a single commercial vendor. Although up2date is closely tied to Red Hat's proprietary Red Hat Network support offering, an up2date server clone is under development. Its feature set is rather limited at present, but Red Hat's new support policy will undoubtedly drive many users to run their own patch servers.
Another tool that could be used is Connectiva's port of Debian's apt package management front-end to Red Hat's RPM format. Running an apt repository is not difficult and provides an excellent mechanism for continued security updates.
All that is necessary is continued community support for the orphaned distributions, in the form of well-managed projects that follow security updates for core OS components, and then build and extensively test new packages on the target platform.
If you think that this sounds like an opportunity for third-party support vendors, you're right about that, too. I suspect that Tummy.com's KRUD distribution which provides monthly updates to a Red Hat-based system, will gain quite a number of customers. I know of at least one other vendor who is considering a Red Hat support offering including packages for older Red Hat versions.
Open source proponents have long claimed that our community can provide better support than any commercial vendor can. Now we'll have to prove it.
Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.