LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsHow long should security embargoes be?Security embargoes are something of a double-edged sword. The idea is to coordinate a release date for a particular security fix between the affected parties (typically distributions in the Linux world). But, while the embargo is in place, no fixes are being issued which increases the length of time that users are vulnerable. That could lead to widespread—or targeted—attacks against vulnerable systems if the flaw is already known, is leaked, or is rediscovered during the embargo period. The chances of that may be relatively small, but they certainly increase as a function of the length of the embargo. It is for those reasons that embargoes in the Linux world are typically short. While proprietary vendors will sometimes sit on a vulnerability for months, Linux embargoes are generally on the order of a week or two. The rules for the acceptable length of an embargo are set by the venue where the information is shared, which for Linux distributions is the closed linux-distros mailing list. There is also an associated distros mailing list which also adds in representatives from some of the BSDs. These two lists have taken the place of the vendor-sec list that was compromised in March 2011. Up until recently, the guidelines for linux-distros specified that the maximum allowable embargo was 14 days. That means that anyone reporting a bug to the list should be willing to wait that long to publicly release any information; it also binds list participants to that deadline. The idea is that anyone who doesn't want to agree to embargoes of up to 14 days shouldn't be using linux-distros. As part of the discussion of the bug and fix on that list, a coordinated release date (CRD) would be chosen so that all distributions would release at the end of the embargo period. List administrator Alexander Peslyak (aka Solar Designer) recently made a change to the guidelines to better reflect reality. There is an effort to avoid having a CRD that falls on a Monday or a Friday to try to not land on a holiday or other inconvenient day for administrators who may need to do lots of updates because of the security fix. That meant that the 14 day maximum sometimes stretched to 19 days, so Peslyak changed the page to reflect that. He also posted to the open oss-security list to highlight the change. There were no complaints about the change, though there were some alternatives suggested (10 business days for example), until Peslyak followed up his message suggesting that perhaps the 14-19 days be reduced to 7-11 days. Even that length of time is longer than he would like, "but I am proposing what I think has a chance to be approved by others without making the list a lot less useful to them". Peslyak also outlined his reasons for preferring shorter embargo windows. Distributions that have the fix ready more quickly can get it into the hands of users sooner, rather than waiting a week or more for the embargo to end. Also, it reduces the window of time in which the vulnerability could be rediscovered or leaked from the list somehow. There are also logistical concerns with longer embargoes including increased tracking of multiple overlapping embargoes. Both Marc Deslauriers of the Ubuntu security team and Kurt Seifried of the Red Hat security response team were quick to disagree with a one-week (more or less) embargo period. Depending on the severity of the bug and the difficulty of the fix, it may be hard for some distributions to pull together, test, and release fixes in that time frame. In particular, Seifried is concerned about volunteer-run distributions that may lack the staff to ensure fixes in a shorter period. But Deslauriers makes another important point:
This means vendors will be keeping information about the vulnerability
private until they are confident they are able to release within a week,
at which point they will then share the information with other vendors
who will scramble to get their updates ready.
As a distro, I now have two choices: I sit on vulnerabilities until our own QA and testing is done, at which point I send them to the list and hope that 7 days is enough for everyone else, or I simply stop using the list for anything that's more than trivial and contact other vendors directly. That's the fine line that Peslyak is walking here. If the embargo requirements become too onerous (or seem that way), distributions may stop reporting to the list—or only report after they have made progress with a fix. But, other lists have other rules. The closed kernel security list says that it will do embargoes up to 7 days, but it seems to rarely happen that way, undoubtedly partially due to Linus Torvalds's distaste for embargoes. That policy may also result in distributions delaying reports to the kernel security list, of course. It should be noted that these "closed" lists have been fairly leaky at times. In addition to the vendor-sec list compromise, the kernel security list may have been breached as part of the kernel.org compromise. The linux-distros list now uses PGP-encrypted emails, which should help unless the host doing the re-encryption to each member's key is breached. There are also dangers from fixes that are rushed, of course. The recent PHP remote code execution vulnerability came about because of a rushed fix for a different security hole. There is certainly value in taking some time to get a security fix right, the only question here is how long that should be, and, for full disclosure types, whether users should be made aware of the problem while the fix is in progress. In the end, the 14-19 day window stayed, though a preference for embargoes of less than 7 days was added. It's a difficult problem, partly because there are so many unknowns. Fixes can be difficult to apply (particularly if they need to be backported) and to test, especially for multiple distribution releases. But the longer the bug is embargoed, the longer users are at risk without any ability to mitigate the problem locally while awaiting a fix. That's why the full disclosure camp believes that information on security holes should be released without delay, so that users are empowered to make their own decisions. That approach is not very popular with vendors, of course. Embargoes and their length is an issue that will likely be debated again and again because there isn't an "obviously correct" solution.
Brief items Distribution quotes of the week
The solution to "My kernel update doesn't boot" should be "Automatically
detect that that happened, give the user that information and fall back
to the old kernel", not "Always show the user a menu that they almost
always don't care about". Solve the actual problem.
-- Matthew Garrett
And so, I intend to wear those shoes proudly. While I don’t plan on
following in the footsteps of anyone (because, you know, that would be
walking in circles, which isn’t highly productive), I do aspire to step
with the same spirit that those before me have — honestly, transparently,
communicative-ly (new word!), with humor, and with care. And I aspire to
Get Stuff Done, sans red tape.
-- Robyn
Bergeron
Anyhow, while I am looking forward to playing around with Debian Wheezy,
the current Debian testing branch, I can foresee Squeeze and my #! Statler
builds remaining on a couple of my boxes for a good while yet. IMHO, the
release still has plenty of legs left in it, even if some people consider
it only fit for servers. Troglodytes!
-- Philip Newborough
Distribution News Debian GNU/Linux bits from the DPL for January 2012Stefano Zacchiroli shares a few bits on his January activities. Various legal issues have kept him busy, including the copyright and licensing of the Debian web site, trademarks, and working with the Debian France association in becoming a Debian Trusted Organization.
Bits from the Debian GNU/Hurd portersThe Debian GNU/Hurd porters have installation media available. These bits also contain their Wheezy release goals. "Since the ftp-master meeting in July 2011, significant improvements have been made, and a technological preview of GNU/Hurd with Wheezy, as was made for kFreeBSD did for Squeeze, is still the target."
Fedora Jared Smith steps down as Fedora project leaderFedora project leader Jared Smith has announced that he is moving on. "I'm happy to announce that Red Hat has selected Robyn Bergeron to be the next Fedora Project Leader. Robyn has proven herself in the Fedora community over the last several years, and I have complete confidence in her abilities to lead the Fedora Project. In addition to planning FUDCon Tempe in 2011 and helping to lead the Marketing and Cloud SIGs within Fedora, Robyn has been an integral part of many other Fedora events and endeavors. Most recently, she has held the role of Fedora Program Manager, helping to ensure that we all stay on schedule and helping the Fedora feature process stay on track."
Ubuntu family Canonical pulls funding from KubuntuKubuntu lead developer Jonathan Riddell has sent out an announcement that Canonical will no longer be funding work on the KDE-based Kubuntu distribution. "The practical changes are I won't be able to work on KDE bits in my work time after 12.04 and there won't be paid support for versions after 12.04. This is a rational business decision, Kubuntu has not been a business success after 7 years of trying, and it is unrealistic to expect it to continue to have financial resources put into it."
Newsletters and articles of interest Distribution newsletters
SUSE hits the big 2-0 (ITWorld)"2012 will be the year of the lizard" says Brian Proffitt, in this nod to SUSE Linux's 20th anniversary this year. "But this relatively long existence almost didn't come to pass, as what began as S.u.S.E. GmbH in 1992 has undergone two major takeovers, a partnership with Microsoft that led to near-revolt in the Linux community, and a heretofore-unknown consideration by Red Hat to purchase the German Linux company just prior to the turn of the century."
Parabola GNU/Linux: Freedom Packaged (OSNews)OSNews takes a look at Parabola GNU/Linux, a recent entry in the GNU list of free distributions. "Parabola developers chose a refreshing approach to limiting the availability of non-free software while maintaining the ability to use Arch mirrors: all the "liberated" (built with special options or otherwise stripped off the non-free parts) packages are included in a separate "libre" repository; the blacklisting of non-free packages is done with a virtual "your-freedom" package that doesn't install any files but conflicts with a long list of packages. Installing this package makes pacman (package manager) remove all the non-free software to resolve conflict or replace it with free analogues if required. "
Page editor: Rebecca Sobol |
|||||||||||||