lkml.org 
[lkml]   [2005]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: thoughts on kernel security issues
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:4.047 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site