[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANTw=MOkHJvDhyfQyH87s447JMyWP_BW+km1fu-AiP_z3or1Cg@mail.gmail.com>
Date: Sun, 3 Mar 2013 22:39:30 -0500
From: Michael Gilbert <mgilbert@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: handling of Linux kernel vulnerabilities (was: CVE
request - Linux kernel: VFAT slab-based buffer overflow)
On Sun, Mar 3, 2013 at 9:12 PM, Greg KH wrote:
> On Mon, Mar 04, 2013 at 05:44:38AM +0400, Solar Designer wrote:
>> In my opinion, it'd be best if Linus, Greg, et al. would reconsider
>> their approach.
>
> Reconsider just what specifically? You bring up a bunch of issues that
> the distros need to consider, what can the Linux kernel security team do
> differently? We were asked to notify the linux-distro list, and now we
> will be doing that. Should we not and just go back to how things were
> before?
Please reconsider the quasi-secret denial state that has been the
kernel security posture for the past 20 years: i.e. the persistent
inability to recognize that the existing approach serves to do more
harm than it does good. Argument supporting that idea follows.
Malicious actors/organizations (the bad guys) have resources, skill,
time, and most importantly motivation (i.e. profit) to be able to
study a sufficient subset of all kernel commits to be able to find a
few that provide them the avenue they need to achieve their malevolent
goals.
The good guys have none of those. They have day jobs, have to produce
new code (rather than reviews) most of the time, have tons of other
bugs to deal with, and most importantly have no monetary incentive to
sit there and study every kernel commit message/patch. Instead, the
good guys rely on a system of trust and generosity, which seems to be
working fairly well on oss-sec in general, but definitely not with the
kernel-land. The persistent secrecy is in direct opposition to trust,
and refusals to spend the little time to write blurbs about issues is
a disservice to users (an ungenerous act), who if they were in the
know, could use that information to be able to solve those problems on
their own (note that's often done by a distro kernel-sec team).
And of course there is that other kicker, the bad guys only need
discover a few bugs. The good guys need to find (and fix) them all,
and that requires information. By keeping that information in this
quasi-secret state, you are guaranteeing a certain (large subset) of
users remain in the dark while some of the malevolent actors are in
the light. That is wrong.
I was getting encouraged by the recent anger-centric posts, the "what
is it that we're supposed to do better?" ones. That gave me some
encouragement that there was the possibility of positive change, but
the "we're not going to make users more unsafe by telling them about
issues affecting them" is a persistence of the denial state. That
logic completely violates the known idiom that knowledge is power:
give users the knowledge that they need to protect themselves, and
they will; starve them of that knowledge, and they remain vulnerable.
Best wishes,
Mike
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.
