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 07:41:10PM +0000, Alan Cox scribbled:
[snip]
> > 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
>
> I'd say you are very very wrong from the data I have access too,
> probably of the order of 1000:1 wrong or more.
I stand corrected then, you have access to much better sources than I do, no
doubts.

> > > 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,
>
> They chose to. A lot of people report bugs directly to Linus too or to
> the lists or to full-disclosure depending upon their view. The folks who
> report bugs in private either to Linus or to vendor-sec or maintainers
> or whoever generally believe that the bad guys can move faster and cause
They can still move faster when the vulnerability (and the fixed vendor
kernels) are released. The people who are to install the kernels usually
cannot act immediately, so if the bad guys have somebody on target, they
will root them anyway. I see no difference here to a model of totally open
disclosure list.

> a lot of damage if a bug isn't fixed before announce.
Again, it works for vendors, not for end users, IMO.

> Thats based on the observation that
> - the bad guys have to move a small exploit versus a large binary
delayed release doesn't change that. One still needs to download and deploy
the kernels (possibly compiling them if they have to).

> - the exploit doesn't have to pass quality assurance, you just write
> more
again, closed mailing lists don't change that

> - they can automate the attack tools very effectively
ditto

> So the non-disclosure argument is perhaps put as "equality of access at
> the point of discovery means everyone gets rooted.". And if you want a
> lot more detail on this read papers on the models of security economics
> - its a well studied field.
Theory is fine, practice is that the closed disclosure list changes matters
for a vaste minority of people - those who are to install the fixed kernels
are in perfectly the same situation they would be in if there was a fully
open disclosure list.

all of this is IMHO, of course - cannot stress that more :)

best regards,

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