[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
