Re: thoughts on kernel security issues

[Chris Wright]

* Linus Torvalds (torvalds@xxxxxxxx) wrote:
> On Wed, 12 Jan 2005, Marcelo Tosatti wrote:
> > How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ? 
> 
> Please realize that I don't have any problem with a short-term embargo per
> se, what I have problems with is the _politics_ that it causes.  For
> example, I do _not_ want this to become a
> 
>  "vendor-sec got the information five weeks ago, and decided to embargo
>   until day X, and then because they knew of the 4-day policy of the
>   kernel security list, they released it to the kernel security list on 
>   day X-4"

I agree, and in most of these cases long delay are due to things
falling through cracks or not getting adequate cycles.  Not so much
politics.

> See? That is playing politics with a security list. That's the part I 
> don't want to have anything to do with. If somebody did that to me, I'd 
> feel pissed off like hell, and I'd say "screw them".
> 
> But in the absense of politics, I'd _happily_ have a self-imposed embargo
> that is limited to some reasonable timeframe (and "reasonable" is
> definitely counted in days, not weeks. And absolutely _not_ in months,
> like apparently sometimes happens on vendor-sec).
> 
> So if the embargo time starts ticking from _first_ report, I'd personally
> be perfectly happy with a policy of, say "5 working days" (aka one week), 
> or until it was made public somewhere else.

That's more or less my take.  Timely response to reporter, timely
debugging/bug fixing and timely disclosure.

> IOW, if it was released on vendor-sec first, vendor-sec could _not_ then
> try to time the technical list (unless they do so in a very timely manner
> indeed).

What about the reverse, and informing vendors?  This is typical...project
security contact gets report, figures out bug, works with vendor-sec on
release date.  In my experience, the long cycles rarely come from that
final negotiation.  It's usually not much of a negotiation, rather a
"heads-up", "thanks".

The two goals: 1) timely response, fix, dislosure; and 2) not leaving
vendors with pants down; don't have to be mutually exclusive.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
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/