lkml.org 
[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: thoughts on kernel security issues
    On Thu, Jan 13, 2005 at 11:50:04AM -0800, Chris Wright scribbled:
    > * Marek Habersack (grendel@caudium.net) wrote:
    > > On Thu, Jan 13, 2005 at 03:36:27PM +0000, Alan Cox scribbled:
    > > > On Mer, 2005-01-12 at 17:42, Marcelo Tosatti wrote:
    > > > > The kernel security list must be higher in hierarchy than vendorsec.
    > > > >
    > > > > Any information sent to vendorsec must be sent immediately for the kernel
    > > > > security list and discussed there.
    > > >
    > > > We cannot do this without the reporters permission. Often we get
    > > I think I don't understand that. A reporter doesn't "own" the bug - not the
    > > copyright, not the code, so how come they can own the fix/report?
    >
    > It's not about ownership. It's about disclosure and common sense.
    > If someone reports something to you in private, and you disclose it
    > publically (or even privately to someone else) without first discussing
    > that with them, you'll lose their confidence. Consequently they won't
    > be so kind to give you forewarning next time.
    I understand that, but I don't see a point in holding the fixes back for the
    majority of people (since the vendors on vendor-sec are a minority and I
    suspect that more people run self-compiled kernels on their servers than the
    vendor kernels, I might be wrong on that). If there is a list that's at
    least half-open (i.e. invitation required, but no CV required :) then there
    is no issue of confidence, is there? And with such list, everybody has
    equal chances - bad, good and the ugly too. Maybe my logic is flawed, but
    that's how I see it - the linux kernel is a piece of open code, accessible
    to all, with all its features, bugs, flaws. So, if the code is open, the
    reports about the code security/bugs should be as open, together with fixes,
    from the day one of finding the bug. Otherwise, if we have the scenario when
    the vendor-sec members are informed about a bug+fix 2 months earlier and the
    vulnerability+fix are disclosed 2 months later, then this is creating a
    situation where not everybody has equal chances of reacting to the bug. As I
    wrote earlier, that puts the folks using non-vendor kernels way behind both
    the vendors _and_ the bad guys - since the latter have both the
    vulnerability, the fix _and_ (usually) the exploit (or they can come up with
    it in a matter of hours). For me it's all about equal chances in reacting to
    the security issues. Again, I might be totally wrong in my reasoning, feel
    free to correct me.

    > > > material that even the list isn't allowed to directly see only by
    > > > contacting the relevant bodies directly as well. The list then just
    > > > serves as a "foo should have told you about issue X" notification.
    > > This sounds crazy. I understand that this may happen with proprietary
    > > software, or software that is made/supported by a company but otherwise opensource
    > > (like OpenOffice, for instance), but the kernel?
    >
    > Licensing is irrelevant. Like it or not, the person who is discovering
    > the bugs has some say in how you deal with the information. It's in our
    > best interest to work nicely with these folks, not marginalize them.
    It's not about marginalizing, because by requesting that their report is
    kept secret for a while and known only to a small bunch of people, you could
    say they are marginalizing us, the majority of people who use the linux
    kernel (us - those who aren't on the vendor-sec list). It's, again IMHO,
    about equal chances. More and more often it seems that security advisories
    and releases are treated as an asset for security companies, not a common
    good/knowledge. And that's pretty sad...

    regards,

    marek
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:3.650 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site