Re: security contact draft

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Thu, Jan 13, 2005 at 01:31:19PM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 13 Jan 2005, Alan Cox wrote:
> > 
> > It's not documenting the stuff Linus seems to be talking about which is
> > a public list ? Or does Linus want both ?
> 
> I see myself as pretty extreme when it comes to my approach to security.
> 
> And I actually distrust extremes. I'm at one end of the spectrum, and
> vendor-sec is at the other (I'm not even counting the head-in-the-sand
> approach as part of the spectrum ;). Knowing that, I'd expect that most
> people are somewhere in between.
> 
> Which to me implies that while what I personally _want_ is total openness, 
> that's not necessarily what makes the most sense in real life.

Gooood :) 

> So I want to give people choice. I want to encourage openness. But hell, 
> if we have a closed list with a declared short embargo that is known to 
> not play games (ie clock starts ticking from original discovery, not from 
> somebody elses embargo), that's good too.
> 
> Let people vote with their feet. If vendor-sec ends up being where all the
> "important" things are discussed - so be it. We've not lost anything, and
> at worst a "kernel-security" list would be a way to discuss stuff that was
> already released by vendor-sec.

On my understanding we are about to win several things.

I rather prefer having vendorsec NOT deal with these issues because 
it gives autonomy to the kernel team. It wont depend on "suspicious" criteria
of embargo's - but instead have a clear written policy for embargo's.

And the timeframe, as Alan says, has to be acceptable for the vendors to 
generate their updates and run the QA process, otherwise things will 
continue to be discussed at vendorsec.

Other than that, by not "wrapping" the fixes with non descritive changelogs,
we will have an official list of security problems. Hey, this is a serious 
operating system.

Wrapping up fixes means "disclosure" for the better informed people 
(the bad guys) who read the changesets, and means "lack of knowledge" 
for the less informed - users who dont run the latest kernel and only 
upgrade in case of public security issues (the majority of them?).

So the argument of "wrapping" up fixes for "better and safer code" is actually
very bad if you think about it. 

Once we have that, there will be a "official" list of known issues.

Those MANY who ask
"I'm using v2.6.12 on my customized kernel and I can't upgrade to the latest
v2.6.20 kernel, which security bugs exist that I need fixed?"

Will have an easy answer.

This is better for the Linux kernel developers, better for vendors and better
for users.