Date: Thu, 3 Mar 2011 15:09:55 -0800 From: Kees Cook <kees@...ntu.com> To: Greg KH <greg@...ah.com> Cc: oss-security@...ts.openwall.com Subject: Re: Vendor-sec hosting and future of closed lists On Thu, Mar 03, 2011 at 01:53:45PM -0800, Greg KH wrote: > On Thu, Mar 03, 2011 at 01:36:40PM -0800, Kees Cook wrote: > > Several upstreams, though disappointingly not the Linux kernel, are very > > good about keeping their end-users in mind and providing direct distro > > coordination for important security updates (MIT Kerberos comes to mind > > first as a great example). > > Note, that is just your opinion about the Linux kernel, not all distros > or developers share that view. I'm certainly speaking for myself, and I'm well aware that there are people who disagree with me. :) Regardless, I should perhaps clarify further... The term "end-user" gets used in a lot of contexts. As I meant it (in a "Linux distribution" context), this term means the person running some stable release of a distro. They're using packages of upstream software, each a snapshot-in-time-maybe-with-patches. Upstreams have "end-users" too, some use tip, and some use stable releases. Some of their stable release end-users are doing so via packaged versions in distros. When a security flaw comes up, an upstream can choose what level to fix it at: 1- fix it privately 2- also commit the fix to tip 3- also fix it in the most recent stable release 4- also fix it in all stable releases in active use by end-users Additionally, when communicating the implication of the fixed flaw, an upstream can choose their level of response: 1- no communication 2- mention security implication in public commit 3- notify interested end-users via central public website/mailinglist 4- notify distributions via public mailinglist 5- notify distributions via private mailinglist (distro-controlled list) 6- notify distributions privately, individually (upstream-controlled list) I took RedHat's comment about direct upstream distro notifications to mean communication style 6. The vendor-sec mailing list was style 5. I was attempting to express that some upstream are now doing this for security flaw fixing: fix 1 communicate via 6 or 5 with coordination of when "fix 2 up to 4" happens fix 2, maybe fix 3, maybe fix 4 communicate 2 communicate 3 and/or 4 This tends to happen for upstreams that feel a responsibility toward their end-users to protect them from security flaws, recognize that a large portion of their end-users are via distros, and that using the above methodology increases the likelihood that end-users will have a flaw fixed in a timely manner without regression. So, I can point to lots of upstreams that perform many variations on the above example. I mentioned MIT Kerberos already where they send out patches for multiple stable versions well in advance of public commit to all the distros privately. Others in similar situations that jump to mind are Firefox and Samba; there are plenty more. I think the maturity of an upstream's response to security flaws can be gauged based on this combination of fix and communication levels. For the end-users using the software as packaged by distros, the distros need to both have fixes and know about them. The level of work required to apply fixes to a distro release of software depends on how high the level of fixing the upstream did. If an upstream provides a patch exactly for a distro's version of software, it's very little work to apply and QA, and the end-user will get a fast and stable distro update. If not, then some amount of comparing notes between distros, more careful testing, etc, is needed and potentially slows down the speed/stability of that end-user's update. Compare the communication/fix continuum of "Here are patches that fixes the flaw for various prior releases" to "Please upgrade to the latest". This latter style does not treat the end-users via distros very well. For upstreams that do not have the time to provide high fix levels, they will instead improve their communication, calling out when a new release is available and fixes security flaws. Upstreams with more time will call out the specific commits that fix flaws, as a guide for packagers. Even this is a big step in the right direction for communication. As I see it, the upstream Linux kernel certainly fixes most flaws discovered, and almost gets to fix level 4 (there are so many variations of the Linux kernel running on end-user's systems, I can't blame the Linux kernel upstream for not offering a patch for every version the majority of their end-users use). Where I am disappointed is in the communication. It's generally somewhere between communication style 1 and 2. There is no central list of fixed flaws (style 3, see almost every major upstream's website and append some variation "/security" to the url, etc), and certainly no central list of fixes. There is frequently no mention of the implication of a flaw in commits (style 2), and nothing like style 4, 5, or 6 happening. The only place these things happen are in each distro's bug trackers, or scattered in the Mitre CVE links (which almost invalidates anything above fix level 2 since there is no certain way to find a flaw's fix in an upstream stable kernel update). So yes, I'm disappointed in the upstream Linux kernel's security flaw fix communications. And while I'm sure some people may not agree with me, I know many do. -Kees -- Kees Cook Ubuntu Security Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.