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.