[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5135621E.2080106@redhat.com>
Date: Mon, 04 Mar 2013 20:10:22 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: handling of Linux kernel vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/04/2013 06:20 PM, Greg KH wrote:
> On Mon, Mar 04, 2013 at 10:12:56PM +0100, Eric Lacombe wrote:
>> Hi,
>>
>> Le lundi 4 mars 2013 11:48:58, Greg KH a écrit :
>>> On Sun, Mar 03, 2013 at 10:39:30PM -0500, Michael Gilbert
>>> wrote:
>>>> 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.
>>>
>>> That's a load of crap.
>>>
>>> Seriously, you know it only benefits the "bad guys" if I were
>>> to say, "This patch just went into Linus's tree that fixes a
>>> security problem that you can exploit in this manner". No user
>>> would have a chance to fix their systems before the
>>> vulnerability was added to the "ultra-sploit" tool and everyone
>>> would have their systems trashed.
>>
>> I think there's a difference between disclosing the vulnerability
>> and disclosing it with a related exploit. The first one allows to
>> fulfill what Michael Gilbert explains without the consequences
>> that you focus on.
>
> You really think there is a difference? I assert that there is
> none, and history has shown that this is the case, but feel free to
> prove me wrong.
>
>> And as Michael Gilbert insisted on, I deeply think that the
>> asymmetry of the problem should be taken into account for
>> defining the way of dealing with security flaws.
>
> Then why do we even have the linux-distros list at all?
>
> greg k-h
It's not just for kernel vulns? At this point I literally don't
understand the conversation, it appears some people have theoretical
concerns about openness/etc. but I'm not seeing anything remotely
evidence based to support their positions. OTOH we have the kernel
devs like Greg who are making arguments based on past
behaviour/evidence of basically what works/what doesn't work. I should
note that the standards and current processes have worked quite well
AFAIK (I've only really been tracking Linux security closely for 14
years now, prior to summer of 1999 I can't really say).
If anyone has really evidence based problems/issues to bring up,
please do so. Otherwise can we stop with all the hand waving, keep
doing what we have been doing which seems to work quite well and let
Greg/etc. get back to work?
If you want to discuss the theoretical/philosophical nature of
information security as applied to the Linux kernel I'd be happy to
set up a separate list for that, OSS-Security isn't really the right
venue.
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJRNWIeAAoJEBYNRVNeJnmTohIQAMMVc7jO9zEe4GUAOU8Zfd1P
lTIBzFPKlz9aAZriT3ONoJXqqduyK/APlSLjfj4DGUuEJ6kM/zg5JafvehOl7aRI
/o0CgcpH4ebFbcR4NQSi5jl0qYnDQe1XiTvVGBehX1ULdXNHb5ID+x956GNHRCKY
zQV2aJTeqOQ1R6BsfGc24rtW0g1OLSGav4dqgPCjdZ5HNSjgI7P1mTN28XheaVjz
grlFELvSBJqGiuqxngDiyNjzzAfC8M/hr+FJrTUzNFBaSqTPbl/PzZCobQ9176gX
v9GtdqwXY+Ww1GWpi3/WX8foAasig2XNlKPyfogzNerLLASqVt66kc509lHrpDmG
tworl82CpGsTe/H5vTZbUFZD8Ja4NtfQfZyVqduo+xoSpZxRoSBOzMoSzmr9qYIr
EGg5V6qV9a06Wn1aJfXAbto4FoBE7UmcZmoej0ALbdDZcw6AONjehBx9vH3cR1zs
69ADe8zLa9QXavu1GFeMgv4aoXeVXMx1MuB8ovJr7vn+RFgmDmA25vd83ssIdSrI
rqY61YCu+kKfcAD1H46n7tXGt/bzQkHmEmnyjOMy0Ds87HCoC4HCaVM4xUTKOkrK
RG9WfeLSdV7EYgl7pRMOB8W5yKDuiICTXzKtr1q7+TVkYzz0UYIbOVAiHS61/I3N
UEoWYnqq6+qRmrx5Ytc3
=ScBC
-----END PGP SIGNATURE-----
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.
