Date: Tue, 14 Nov 2017 17:43:51 +0000 From: Eddie Chapman <eddie@...k.net> To: oss-security@...ts.openwall.com, Brad Spengler <spender@...ecurity.net> Cc: Vladis Dronov <vdronov@...hat.com> Subject: Re: CVE-2017-15102: Linux kernel: usb: NULL-deref due to a race condition in [legousbtower] driver On 14/11/17 12:32, Brad Spengler wrote: > Hi Greg, > > We're all aware of your objection, you bring it up every time > anyone mentions Linux kernel security on this list. However, > please remember that all the people contributing on this list are > taking on the responsiblity you and the majority of other upstream > developers have abdicated. Does Linus, Greg, Al, etc, etc, etc owe anyone anything? Yes, they're time is paid by companies and/or the Linux Foundation, but do those orgs have a responsibility to anyone? They're working incredibly hard on probably one of the most difficult project management feats anyone could attempt, which anyone can take the end results of, and use without monetary cost. Linus has the right to treat security in whatever way he wishes to, according to his own personal philosophy, ultimately it is his project and he answers to no-one other than himself. You say everyone on this list is taking on this "responsibility". So what? Some are making a living or business out of that. Maybe it is right that the "community" sifts through all the bug fixes and identifies issues that have a security impact. Kernel development is hard enough, someone committing a fix has already done a lot of work. Do they have an obligation to do the extra thinking and documenting in the commit log in order to identify how someone might maliciously take advantage of a flaw? It seems we have a whole industry of people who are good at that, so why shouldn't that industry take on that task? Would you, Brad, be in business with your product if the kernel people handled security perfectly? I have nothing against grsecurity and your efforts, I see no harm in companies making a business out of kernel security. > Vladis' original mail made it clear the bug was > already fixed with the included upstream fix link, so your > follow-up was unnecessary. I don't see a problem on this list with too many people making unnecessary, frivolous contributions. If you feel your rant was worthy of being posted, then I'd say Greg's comments, which were polite and without a hint of vitriol, were also worthy of contribution. I think you should leave it up to the moderator who does a good job of supervising this list, rather than suggesting that anyone's comments are unnecessary. > If you truly believe there is no uniqueness to security bugs, I > would advise you to shut down security@...nel.org. Regardless of what anyone at the top of the kernel project may have said in the past, I think the reality shows that kernel people on the whole take security relatively seriously. After all, nearly everyone involved is a user as well as a developer, and I don't think any of them would seriously claim to not have any concerns about their own boxen getting compromised. Yes, there is room for improvement, and reaction to individual security issues can be debated, but it is unfair to characterise the kernel community as not caring at all about security. Personally I see a lot of examples of kernel people genuinely making efforts to make the kernel more secure, and very few (by comparison), isolated cases of issues being dismissed, or security impact being downplayed. I'm sure examples can be dragged up from the past involving prominent people. But I've seen plenty of evidence of a genuine desire (even on the part of Linus himself, in what he writes in commit logs) to make the kernel more secure, not less. > I would also > ask that you come up with a better solution to the problem than > demanding people run the latest version of Linux. According to my > current records someone taking that advice would be exposed to a > bug that can brick systems that seems nowhere close to resolution, > and one that makes it impossible to run KVM guests on AMD (which went > unfixed for 3 months, and the current fix isn't cc'd for stable -- > makes me wonder how much testing -rc really gets). Regardless of what anyone might *say*, the reality is that there is no reason for anyone to feel compelled to run the very latest kernel in order to stay secure. The list of kernels receiving regular backported fixes is frankly more than is really needed. Greg himself goes above and beyond in this regard and works incredibly hard in maintaining, at the time of writing, 3.18 (unofficially), 4.4, 4.9, and 4.13, usually with 2 or 3 releases a month each. All branches have well defined projected EOL dates. If that is not enough, there are other people actively maintaining 3.2, 3.10 (though just became EOL), 3.16 and 4.1! And that is just the vanilla kernels, when you factor in distro kernels with their own kernel teams backporting security fixes, the choice of secure kernels to run is incredible, we've never had it so good. > You might want to focus your time on getting your own house in > order instead of constantly pestering the people on this list -- we > work in the trenches and aren't swayed by nonsense arguments that > have no viable solution attached. I think the kernel community can hardly be characterised as needing to put its "house in order", that is a gross exaggeration. It's not perfect and improvemets are needed. I welcome the efforts Greg is making to improve things, and his efforts to participate here, and I certainly don't think Brad speaks for everyone, at least not for me. Eddie > > Thanks, > -Brad > > On Tue, Nov 14, 2017 at 08:37:20AM +0100, Greg KH wrote: >> On Mon, Nov 13, 2017 at 07:42:27PM -0500, David A. Wheeler wrote: >>> On Mon, 13 Nov 2017 16:15:24 +0100, Greg KH <greg@...ah.com> wrote: >>>> It's the arbitrarily nature here that I am curious about, it feels like >>>> it should be "all or nothing", for CVEs to mean much here. Right now it >>>> seems like it is just, "all that we care to track"? :) >>> >>> "All" would be awesome, though unlikely. But even if that's the eventual goal, >>> "good starts" are still good starts. >> >> But really, this isn't even a "good start", it's identifying a bug fixed >> over a year ago for a kernel that only one company seems to care about >> because they are _not_ following the recommended upstream stable kernel >> patches because they "know better" :) >> >> That's my objection here. >> >> thanks, >> >> greg k-h
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ