[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
