Re: thoughts on kernel security issues

[Dave Jones]

On Wed, Jan 12, 2005 at 06:09:31PM -0800, Linus Torvalds wrote:

 > Yes, I think delayed disclosure is broken. I think the whole notion of 
 > "vendor update available when disclosure happens" is nothing but vendor 
 > politics, and doesn't help _users_ one whit.

The volume of traffic we as a vendor get every time an issue
makes news (and sadly even the insignificant issues seem to be
making news these days) from users wanting to know where our
updates are is a good indication that your thinking is clearly bogus.

 > The only thing it does is allow the vendor to point fingers and say "hey, we
 > have an update, now it's your problem".

I fail to see the point you're trying to make here.

 > So it's embarrassing to everybody if the kernel.org kernel has a security
 > hole for longer than vendor kernels, but at the same time, most _users_
 > run vendor kernels anyway, so maybe the current setup is the proper one,
 > and the kernel.org kernel _should_ be the last one to get the fix.  

I think the timelyness isn't the issue, the issue is making sure that
the kernel.org kernel actually does end up getting the fixes.
That 2.6.10 got out of -rc with known vulnerabilities which were
known to be fixed in 2.6.9-ac is mind-boggling.  That a 2.6.10.1
didn't follow up yet is equally so.

Part of the premise of the 'new' development model was that vendor kernels
were where people go for the 'super-stable kernel', and the kernel.org
kernel may not be quite so polished around the edges. This seems to
go against what you're saying in this thread which reads..
'kernel.org kernels might not be as stable as vendor kernels, but you're
 going to need to run it if you want security holes fixed asap'

 > Whatever. I happen to believe in openness, and vendor-sec does not. It's
 > that simple.

That openness comes at a price. I don't need to bore you with
analogies, as you know as well as I do how wide and far Linux
is deployed these days, but doing this openly is just irresponsible.

Someone malicious on getting the announcement of a new kernel.org release
gets told exactly where the hole is and how to exploit it.
All they'll need to do is find a target running a vendor kernel before
updates get deployed.  Whilst this is true to a certain degree
today, as not everyone deploys security updates in a timely manner
(some not at all), things can only get worse.

		Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/