A lengthy and interesting thread was started on the lkml by Chris Wright looking to define a centralized place to report security issues in the Linux Kernel. Chris offered his services in getting things set up, addressing his email to Linus Torvalds, Andrew Morton [interview], Alan Cox [interview] and Marcelo Tosatti [interview]. He explained that he wanted to centralize the information "to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure". The resulting discussion was joined by numerous members of the kernel hacking community, exposing a wide range of opinions.

Linus agreed that it sounded like a good idea, but qualified this by adding, "the _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with." An embargo in this case is the time period from when a security problem is first reported to when a fix can be made public. Marcelo pointed out that a certain amount of time is necessary, "for the vendors to catch up", explaining that "it is a simple matter of synchronization". Linus again stressed his dislike for the vendor-sec mailing list suggesting that at times the length of the embargo period is often more about politics than anything else. He then added, "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)." In a followup comment he clarified, "btw, the only thing I care about is the embargo on the _fix_", noting that he was comfortable if there was a need to delay publishing an explanation of the security hole so long as the fix itself was quickly released.

Throughout the discussion, Linus stressed that his preference was to keep everything in the open. He compared this open methodology to that of Microsoft saying, "does Linux have a better track record than MS? Damn right it does. We've had fewer problems, and I think there are more people out there standing up for what's right anyway. Less PR people deathly afraid of rocking the boat. Better technology, and fewer horrid design mistakes." That said, he agreed that some people might be more comfortable being able to report their bugs to a private kernel developer mailing list instead of the completely open lkml, ensuring that the security hole is fixed before it reaches the general public. For this reason, he was in favor of offering several reporting choices to people. He explained, "it's not a black-and-white thing. I refuse to believe that most security problems are found by people without any morals. I believe that somewhere in the middle is where most people feel most comfortable."

In followup, Chris drafted a security contact policy "to keep the conversation concrete". The end result will likely be the creation of an invite-only mailing list to which people can choose to report security problems. Whether or not this list is actually used was unimportant to Linus, just that it was an available choice. "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."

From: Chris Wright [email blocked]
To:  akpm, [email blocked], torvalds [email blocked], alan [email blocked], marcelo.tosatti [email blocked]
Subject: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 09:48:07 -0800

This same discussion is taking place in a few forums.  Are you opposed to
creating a security contact point for the kernel for people to contact
with potential security issues?  This is standard operating procedure
for many projects and complies with RFPolicy.

http://www.wiretrip.net/rfp/policy.html

Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
It would be nice to have a more centralized place for all of this
information to help track it, make sure things don't fall through
the cracks, and make sure of timely fix and disclosure.

In addition, I think it's worth considering keeping the current stable
kernel version moving forward (point releases ala 2.6.x.y) for critical
(mostly security) bugs.  If nothing else, I can provide a subset of -ac
patches that are only that.

I volunteer to help with _all_ of the above.  It's what I'm here for.
Use me, abuse me ;-)


thanks,
-chris

===== MAINTAINERS 1.269 vs edited =====
--- 1.269/MAINTAINERS	2005-01-10 17:29:35 -08:00
+++ edited/MAINTAINERS	2005-01-11 13:29:23 -08:00
@@ -1959,6 +1959,11 @@ M: [email blocked]
 W:	http://www.weinigel.se
 S:	Supported
 
+SECURITY CONTACT
+P:	Security Officers
+M:	kernel-security@{vger.kernel.org, osdl.org, wherever}
+S:	Supported
+
 SELINUX SECURITY MODULE
 P:	Stephen Smalley
 M: [email blocked]
===== REPORTING-BUGS 1.2 vs edited =====
--- 1.2/REPORTING-BUGS	2002-02-04 23:39:13 -08:00
+++ edited/REPORTING-BUGS	2005-01-10 15:35:10 -08:00
@@ -16,6 +16,9 @@ code relevant to what you were doing. If
 describe how to recreate it. That is worth even more than the oops itself.
 The list of maintainers is in the MAINTAINERS file in this directory.
 
+      If it is a security bug, please copy the Security Contact listed
+in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.
+
       If you are totally stumped as to whom to send the report, send it to
 [email blocked]. (For more information on the linux-kernel
 mailing list see http://www.tux.org/lkml/).



From: Marcelo Tosatti [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 13:06:12 -0200


Hi Chris!

On Wed, Jan 12, 2005 at 09:48:07AM -0800, Chris Wright wrote:
> This same discussion is taking place in a few forums.  Are you opposed to
> creating a security contact point for the kernel for people to contact
> with potential security issues?  This is standard operating procedure
> for many projects and complies with RFPolicy.
> 
> http://www.wiretrip.net/rfp/policy.html
> 
> Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
> It would be nice to have a more centralized place for all of this
> information to help track it, make sure things don't fall through
> the cracks, and make sure of timely fix and disclosure.

I very much like the idea and I also think a "official" list of kernel security issues and 
respective fixes is very much required, since not every Linux distribution is supposed
to have kernel developers working for them, going through the whole changelogs 
looking for security issues, which is just silly.

Disclosing and bookkeeping of security issues is a job of the Linux kernel team.

Alan used to list down security fixes between each v2.2 release, v2.4 has never 
had such an official list (I'm trying to write CAN numbers on the changelogs lately), 
neither v2.6. Its not a practical thing for Linus/Andrew to do, its a lot of
work.

It would be interesting to have all developers to know about such initiative 
and have them send their security fixes to be logged and disclosed - its obviously
impossible for you to read all changes in the kernel. And have Linus/Andrew 
advocate in favour of it.

IMO such initiative needs to be known by all contributors for
it to be effective.

> In addition, I think it's worth considering keeping the current stable
> kernel version moving forward (point releases ala 2.6.x.y) for critical
> (mostly security) bugs.  If nothing else, I can provide a subset of -ac
> patches that are only that.

Yes, -ac has been playing that role. It is general consensus that 
such point releases are required. 

Linus doesnt do it because it is too much extra work him (and he is focused
on other things), glad you have stepped up.

> I volunteer to help with _all_ of the above.  It's what I'm here for.
> Use me, abuse me ;-)

You've been doing a lot of security work/auditing in the kernel for a long time, 
which fits the job position nicely.

I'm willing to help.



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 10:05:34 -0800 (PST)



On Wed, 12 Jan 2005, Chris Wright wrote:
>
> This same discussion is taking place in a few forums.  Are you opposed to
> creating a security contact point for the kernel for people to contact
> with potential security issues?  This is standard operating procedure
> for many projects and complies with RFPolicy.

I wouldn't mind, and it sounds like a good thing to have. The _only_
requirement that I have is that there be no stupid embargo on the list.
Any list with a time limit (vendor-sec) I will not have anything to do
with.

If that means that you can get only the list by invitation-only, that's
fine. 

		Linus



From: Chris Wright [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 10:44:07 -0800

* Linus Torvalds [email blocked] wrote:
> On Wed, 12 Jan 2005, Chris Wright wrote:
> > This same discussion is taking place in a few forums.  Are you opposed to
> > creating a security contact point for the kernel for people to contact
> > with potential security issues?  This is standard operating procedure
> > for many projects and complies with RFPolicy.
> 
> I wouldn't mind, and it sounds like a good thing to have. The _only_
> requirement that I have is that there be no stupid embargo on the list.
> Any list with a time limit (vendor-sec) I will not have anything to do
> with.

Right, I know you don't like the embargo stuff.

> If that means that you can get only the list by invitation-only, that's
> fine. 

Opinions on where to set it up?  vger, osdl, ...?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 10:57:25 -0800 (PST)



On Wed, 12 Jan 2005, Chris Wright wrote:
> 
> Right, I know you don't like the embargo stuff.

I'd very happy with a "private" list in the sense that people wouldn't 
feel pressured to fix it that day, and I think it makes sense to have some 
policy where we don't necessarily make them public immediately in order to 
give people the time to discuss them. 

But it should be very clear that no entity (neither the reporter nor any
particular vendor/developer) can require silence, or ask for anything more
than "let's find the right solution". A purely _technical_ delay, in other
words, with no politics or other issues involved.

Otherwise it just becomes politics:  you end up having security firms that
want a certain date because they want a PR blitz, and you end up having
vendors who want a certain date because they have release issues.

Does that mean that vendor-sec would end up being used for some things,
where people _want_ the politics and jockeying for position?  Probably.
But having a purely technical alternative would be wonderful.

> > If that means that you can get only the list by invitation-only, that's
> > fine. 
> 
> Opinions on where to set it up?  vger, osdl, ...?

I don't personally think it matters. Especially if we make it very clear 
that it's purely technical, and no vendor politics can enter into it. 
Whatever ends up being easiest. 

		Linus



From: Chris Wright [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 11:21:37 -0800

* Linus Torvalds [email blocked] wrote:
> On Wed, 12 Jan 2005, Chris Wright wrote:
> > 
> > Right, I know you don't like the embargo stuff.
> 
> I'd very happy with a "private" list in the sense that people wouldn't 
> feel pressured to fix it that day, and I think it makes sense to have some 
> policy where we don't necessarily make them public immediately in order to 
> give people the time to discuss them. 

That's what I figured you meant.

> But it should be very clear that no entity (neither the reporter nor any
> particular vendor/developer) can require silence, or ask for anything more
> than "let's find the right solution". A purely _technical_ delay, in other
> words, with no politics or other issues involved.

Agreed.

> Otherwise it just becomes politics:  you end up having security firms that
> want a certain date because they want a PR blitz, and you end up having
> vendors who want a certain date because they have release issues.

There is value in coordinating with vendors, namely to keep them from

being caught with pants down.  But vendor-sec already does this part
well enough.

> Does that mean that vendor-sec would end up being used for some things,
> where people _want_ the politics and jockeying for position?  Probably.
> But having a purely technical alternative would be wonderful.
> 
> > > If that means that you can get only the list by invitation-only, that's
> > > fine. 
> > 
> > Opinions on where to set it up?  vger, osdl, ...?
> 
> I don't personally think it matters. Especially if we make it very clear 
> that it's purely technical, and no vendor politics can enter into it. 
> Whatever ends up being easiest. 

Well, easiest for me is here ;-)

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net



From: Greg KH [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 10:51:33 -0800

On Wed, Jan 12, 2005 at 10:05:34AM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 12 Jan 2005, Chris Wright wrote:
> >
> > This same discussion is taking place in a few forums.  Are you opposed to
> > creating a security contact point for the kernel for people to contact
> > with potential security issues?  This is standard operating procedure
> > for many projects and complies with RFPolicy.
> 
> I wouldn't mind, and it sounds like a good thing to have. The _only_
> requirement that I have is that there be no stupid embargo on the list.
> Any list with a time limit (vendor-sec) I will not have anything to do
> with.
> 
> If that means that you can get only the list by invitation-only, that's
> fine. 

So you would be for a closed list, but there would be no incentive at
all for anyone on the list to keep the contents of what was posted to
the list closed at any time?  That goes against the above stated goal of
complying with RFPolicy.

I understand your dislike of having to wait once you know of a security
issue before making the fix public, but how should distros coordinate
fixes in any other way?

thanks,

greg k-h



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 11:01:42 -0800 (PST)



On Wed, 12 Jan 2005, Greg KH wrote:
> 
> So you would be for a closed list, but there would be no incentive at
> all for anyone on the list to keep the contents of what was posted to
> the list closed at any time?  That goes against the above stated goal of
> complying with RFPolicy.

There's already vendor-sec. I assume they follow RFPolicy already. If it's 
just another vendor-sec, why would you put up a new list for it?

In other words, if you allow embargoes and vendor politics, what would the 
new list buy that isn't already in vendor-sec.

When I saw how vendor-sec worked, I decided I will never be on an embargo 
list. Ever. That's not to say that such a list can't work - I just 
personally refuse to have anything to do with one. Whether that matters or 
not is obviously an open question.

		Linus



From: Marcelo Tosatti [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 14:12:27 -0200

On Wed, Jan 12, 2005 at 11:01:42AM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 12 Jan 2005, Greg KH wrote:
> > 
> > So you would be for a closed list, but there would be no incentive at
> > all for anyone on the list to keep the contents of what was posted to
> > the list closed at any time?  That goes against the above stated goal of
> > complying with RFPolicy.

> 
> There's already vendor-sec. I assume they follow RFPolicy already. If it's 
> just another vendor-sec, why would you put up a new list for it?
> 
> In other words, if you allow embargoes and vendor politics, what would the 
> new list buy that isn't already in vendor-sec.
> 
> When I saw how vendor-sec worked, I decided I will never be on an embargo 
> list. Ever. That's not to say that such a list can't work - I just 
> personally refuse to have anything to do with one. Whether that matters or
> not is obviously an open question.

Of course it matters Linus - vendors need time to prepare their updates. You 
can't ignore that, and you can't "have nothing to do with it". 

You seem to dislike the way embargos have been done on vendorsec, fine. They can
be done on a different way, but you have to understand that you and Andrew
need to follow and agree with the embargo.

How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ? 

The only reason for this is to have "time for the vendors to catch up", which 
can be defined by the kernel security office. Nothing more - no vendor politics
involved.

It is a simple matter of synchronization.



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 12:00:52 -0800 (PST)



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"

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.

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).

I'm not saying that we'd _have_ to go public after five days. I'm saying
that after that, there would be nothing holding it back (but maybe the
technical discussion on how to _fix_ it is still on-going, and that might
make people just not announce it until they're ready).

		Linus



From: Marcelo Tosatti [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 15:42:03 -0200

On Wed, Jan 12, 2005 at 12:00:52PM -0800, Linus Torvalds 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"
> 
> 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".

An important thing is that Mr. Torvalds agrees with the embargo, which you never
did, you always applied corrections for security bugs without being concerned
about a disclosure date agreement (which you have your own reasons and arguments 
for, OK).

That makes vendorsec/etc uncomfortable submitting the information to you. 

Great to hear you think differently and is willing to agree on a reasonable
embargo period.

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.

I'm sure one week is enough for vendors to prepare updates, and I'm sure they 
will be fine with it.

> 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).

We all agree there is no good reason to embargo a kernel bug for more than 
one week, given that the fix is known and settled.

> 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.
>
> 
> 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).
>
> I'm not saying that we'd _have_ to go public after five days. I'm saying
> that after that, there would be nothing holding it back (but maybe the
> technical discussion on how to _fix_ it is still on-going, and that might
> make people just not announce it until they're ready).

Wonderful.



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 15:36:27 +0000

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
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.

If you are setting up the list also make sure its entirely encrypted
after the previous sniffing incident.

Alan



From: Marcelo Tosatti [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 15:22:31 -0200

On Thu, Jan 13, 2005 at 03:36:27PM +0000, Alan Cox wrote:
> 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
> 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.

Well the reporters, and vendorsec, have to be aware that the 
"kernel security list" is the main discussion point of kernel security issues.

If the embargo period is reasonable for vendors to prepare their updates and 
do necessary QA, there should be no need for kernel issues to be coordinated 
(and embargoed) on vendorsec anymore. Does it make sense?
Of course vendorsec gets informed of what is happening at "kernel security list".

The main reason for reporters to require "permission" to spread the information
is because they want make a PR of their discovery, yes?

In that case they should be aware that submitting to vendorsec means submitting
to kernel security, and that means X days of embargo period.

> If you are setting up the list also make sure its entirely encrypted
> after the previous sniffing incident.

Definately, I asked Chris about it...



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 21:20:49 +0000

On Iau, 2005-01-13 at 17:22, Marcelo Tosatti wrote:
> Well the reporters, and vendorsec, have to be aware that the 
> "kernel security list" is the main discussion point of kernel security issues.

As it should be - I'd rather Linus was fixing these bugs than some of
the other stuff that comes out. The fix quality would go up markedly.

> If the embargo period is reasonable for vendors to prepare their updates and 
> do necessary QA, there should be no need for kernel issues to be coordinated 
> (and embargoed) on vendorsec anymore. Does it make sense?

vendor-sec was never intended to be a kernel security list, it became
one by necessity. Its mostly actually talking about crap like gaim,
xpdf, gaim, gaim again. Its a contact point for any security problem
related to Linux and then normally works with the authors unless they
don't want to work with us.

> The main reason for reporters to require "permission" to spread the information
> is because they want make a PR of their discovery, yes?

Sometimes. Others like CERT have set disclosure dates across many
vendors already and aren't in the PR business so much as the "this is a
linux and windows and apple bug" business. Most of those cross platform
bugs are user space but far from all. 

> In that case they should be aware that submitting to vendorsec means submitting
> to kernel security, and that means X days of embargo period.

Then if the dates don't suit them they won't submit to vendor-sec and
we'll have to set up vendor-sec-two for them or build individual
relationships which are bound to mean the small vendors suffer. We can
push them, we can ask them to report to linux-security but we can't make
them jump. 

Alan



From: Chris Wright [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 11:50:04 -0800

* Marek Habersack [email blocked] 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.

> > 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.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net



From: Marek Habersack [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 21:29:05 +0100

On Thu, Jan 13, 2005 at 11:50:04AM -0800, Chris Wright scribbled:
> * Marek Habersack [email blocked] 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



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 19:41:10 +0000

On Iau, 2005-01-13 at 20:29, Marek Habersack wrote:
> 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

vendor-sec probably covers the majority of users

It covers
	2.4
	2.6-ac
	Red Hat
	SuSE
	Debian
	Gentoo
	Mandrake
	and many more including some of the BSD folk (a lot of user space bugs
are common)

2.6 base isn't covered because Linus has differing views.

> 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.

> > 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
a lot of damage if a bug isn't fixed before announce.

Thats based on the observation that
	- the bad guys have to move a small exploit versus a large binary
	- the exploit doesn't have to pass quality assurance, you just write
more
	- they can automate the attack tools very effectively 

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.

Alan



From: Arjan van de Ven [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 21:57:17 +0100

On Thu, 2005-01-13 at 19:41 +0000, Alan Cox wrote:

> 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.

or in other words: you can write an exploit faster than y ou can write
the fix, so the thing needs delaying until a fix is available to make it
more equal.



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 13:22:28 -0800 (PST)



On Thu, 13 Jan 2005, Arjan van de Ven wrote:
>
> On Thu, 2005-01-13 at 19:41 +0000, Alan Cox wrote:
> 
> > 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.
> 
> or in other words: you can write an exploit faster than y ou can write
> the fix, so the thing needs delaying until a fix is available to make it
> more equal.

That's a bogus argument, and anybody who looks at MS practices and 
is at all honest with himself should see it as a bogus argument.

I think MS _still_ to this day will stand up and say that they have had no
zero-day exploits. Exactly because they count "zero-day" as the day things
get publically released. Never mind that exploits where (and are)  
privately available on cracking networks for months before. They just
haven't been publically released BECAUSE EVERYBODY IS PARTICIPATING IN THE
GAME.

The written rule in this community is "no honest person will report a bug
before its time is through". Which automatically means that you get 
branded as being "bad" if you ever rock the boat. That's a piece of 
bullshit, and anybody who doesn't admit it is being totally dishonest with 
himself.

Me, I consider that to be dirty.

Does Linux have a better track record than MS? Damn right it does. We've 
had fewer problems, and I think there are more people out there standing 
up for what's right anyway. Less PR people deathly afraid of rockign the 
boat. Better technology, and fewer horrid design mistakes.

But that doesn't mean that all the same things aren't true for vendor-sec 
that are true for MS. They are just bad to a (much, I hope) smaller 
degree.

So instead, let's look at FACTS:

 - fixing a security bug is almost always much easier than writing an 
   exploit.  Arjan, your argument simply isn't true except for the worst 
   possible fundamental design issues. You should know that. In the case 
   of "uselib()", it was literally four lines of obvious code - all the 
   rest was just to make sure that there weren't any other cases like that
   lurking around.

 - There are more white-hats around than black-hats, but they are often 
   less "driven" and motivated. Now _that_, I would argue, is the real 
   problem with early disclosure - motivation.  The people really 
   motivated to find the bugs are the people who are also motivated to
   mis-use them. However, vendor-sec and "the game" just makes it more 
   worth-while for security firms to participate in it - it gives them the 
   "good PR" thing. And how much can you trust the "gray hats"?

And this is why I believe vendor-sec is part of the problem. If you don't
see that, then you're blinding yourself to the downsides, and trying to
only look at the upsides.

Are there advantages and upsides? Yes. Are there disadvantages?  
Indubitably. And anybody who disregards the disadvantages as "inevitable"
is not really interested in fixing the game.

			Linus



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 21:15:41 +0000

On Iau, 2005-01-13 at 21:22, Linus Torvalds wrote:
> Are there advantages and upsides? Yes. Are there disadvantages?  
> Indubitably. And anybody who disregards the disadvantages as "inevitable"
> is not really interested in fixing the game.

So the next time I find a remote root hole I should post an exploit
example targetting kernel.org to the linux-kernel list ? Now where are
you going to publish the fix - bk is down, kernel.org is down ...


Disclosre isn't quite as simple as you'd like.



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 14:41:29 -0800 (PST)



On Thu, 13 Jan 2005, Alan Cox wrote:
>
> On Iau, 2005-01-13 at 21:22, Linus Torvalds wrote:
> > Are there advantages and upsides? Yes. Are there disadvantages?  
> > Indubitably. And anybody who disregards the disadvantages as "inevitable"
> > is not really interested in fixing the game.
> 
> So the next time I find a remote root hole I should post an exploit
> example targetting kernel.org to the linux-kernel list ? Now where are
> you going to publish the fix - bk is down, kernel.org is down ...
> 
> Disclosre isn't quite as simple as you'd like.

This is like saying "somebody will do the bad thing, it might as well be 
me". I don't believe that is a basis for doing things right.

First off, I've tried to make it clear that while I believe in openness, 
my beliefs are not exclusive to anybody elses beliefs. I'd rather see 
shades of gray than absolute black-and-white.

Secondly, I'd much rather have the mindset where we try to minimize the
likelihood of a catastrophic failure. That includes having many
_different_ ways of gettign things out: Bk, tar-balls, email. Diversity is
a _fundamental_ security strength. It also includes having diversity in 
other areas, ie multiple architectures.

I see vendor-sec as trying to treat the symptoms. It's a "take two
aspirins, call me in the morning". And you seem to not even want to
discuss treating the disease - and vendor-sec is PART of the disease. It's
the drug that people get addicted to when they decided to treat the
symptoms.

I think Linux - just by the source being open - has one real treatmeant to 
one fundamental -cause- of insecurity, namely "we don't care, and we'll 
put our heads in the sane". Open source just doesn't allow that mentality.

And similarly, I think truly open disclosure is another fundamental 
-treatment-, in that it doesn't _allow_ the mentality that vendor-sec 
tends to instill in people.  Well, maybe not "treatment" per se: it's more 
like admitting you have a problem.

It's like alcoholism. Admitting you have a problem is the first step. 
vendor-sec is the band-aid that allows you to try to ignore the problem 
("I can handle it - I could stop any day").

		Linus



From: Dave Jones [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 15:03:08 -0500

On Thu, Jan 13, 2005 at 08:42:46PM +0100, Marek Habersack 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?

Security researchers are an odd bunch. They're very attached to their
bugs in the sense they want to be the ones who get the glory for
having reported it.

As soon as bugs start getting forwarded around between lists, the
potential for leaks increases greatly. The recent fiasco surrounding
one of the isec.pl holes was believed to have been caused due to
someone 'sniffing upstream' for example.

When issues get leaked, the incentive for a researcher to use the
same process again goes away, which hurts us.  Basically, trying
to keep them happy is in our best interests.

		Dave



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 12:10:33 -0800 (PST)



On Thu, 13 Jan 2005, Dave Jones wrote:
> 
> When issues get leaked, the incentive for a researcher to use the
> same process again goes away, which hurts us.  Basically, trying
> to keep them happy is in our best interests.

Not so.

_balancing_ their happiness with our needs is what's in our best
interests. Yes, we should encourage them to tell us, but totally bending
over backwards is definitely the wrong thing to do.

In fact, right now we seem to encourage even people who do _not_
necessarily want the delay and secrecy to go over to vendor-sec, just
because the vendor-sec people are clearly arguing even against
alternatives.

Which is something I do not understand. The _apologia_ for vendor-sec is 
absolutely stunning. Even if there are people who want to only interface 
with a fascist vendor-sec-style absolute secrecy list, THAT IS NOT AN 
EXCUSE TO NOT HAVE OPEN LISTS IN _ADDITION_!

In other words, I really don't understand this total subjugation by people 
to the vendor-sec mentaliy. It's a disease, I tell you.

			Linus



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 19:27:42 +0000

On Iau, 2005-01-13 at 20:10, Linus Torvalds wrote:
> In fact, right now we seem to encourage even people who do _not_
> necessarily want the delay and secrecy to go over to vendor-sec, just
> because the vendor-sec people are clearly arguing even against
> alternatives.

 If someone posts something to vendor-sec that says "please tell Linus"
we would. If someone posts to vendor-sec saying "I posted this to
linux-kernel here's a heads up" its useful. If you are uber cool elite 0
day disclosure weenie you post to full-disclosure or bugtraq. There are
alternatives 8)

> Which is something I do not understand. The _apologia_ for vendor-sec is 
> absolutely stunning. Even if there are people who want to only interface 
> with a fascist vendor-sec-style absolute secrecy list, THAT IS NOT AN 
> EXCUSE TO NOT HAVE OPEN LISTS IN _ADDITION_!

I'm all for an open list too. Its currently called linux-kernel. Its
full of such reports, and most of them are about new code or trivial
holes where secrecy is pointless. Having an open linux-security list so
they don't get missed as the grsecurity stuff did (and until I got fed
up of waiting the coverity stuff did) would help because it would make
sure that it didn't get buried in the noise.

Similarly it would help if you are sneaking security fixes in (as you do
regularly) you actually told the vendors about them.

Alan



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 13:03:22 -0800 (PST)



On Thu, 13 Jan 2005, Alan Cox wrote:
> 
> I'm all for an open list too. Its currently called linux-kernel. Its
> full of such reports, and most of them are about new code or trivial
> holes where secrecy is pointless. Having an open linux-security list so
> they don't get missed as the grsecurity stuff did (and until I got fed
> up of waiting the coverity stuff did) would help because it would make
> sure that it didn't get buried in the noise.

Yes. But I know people send private emails because they don't want to 
create a scare, so I think we actually have several levels of lists:

 - totally open: linux-kernel, or an alternative with lower noise

   We've kind of got this, but things get lost in the noise, and "white 
   hat" people don't like feeling guilty about announcing things.

 - no embargo, no rules, but "private" in the sense that it's supposed to 
   be for kernel developers only or at least people who won't take 
   advantage of it.

   _I_ think this is the one that makes sense. No hard rules, but private 
   enough that people won't feel _guilty_ about reporting problems. Right 
   now I sometimes get private email from people who don't want to point
   out some local DoS or similar, and that can certainly get lost in the
   flow.

 - _short_ embargo, for kernel-only. I obviously believe that vendor-sec 
   is whoring itself for security firms and vendors. I believe there would 
   be a place for something with stricter rules on disclosure.

 - vendor-sec. The place where you can play any kind of games you want.

It's not a black-and-white thing. I refuse to believe that most security 
problems are found by people without any morals. I believe that somewhere 
in the middle is where most people feel most comfortable.

		Linus



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 21:25:07 +0000

On Iau, 2005-01-13 at 21:03, Linus Torvalds wrote:
> On Thu, 13 Jan 2005, Alan Cox wrote:
>  - no embargo, no rules, but "private" in the sense that it's supposed to 
>    be for kernel developers only or at least people who won't take 
>    advantage of it.
> 
>    _I_ think this is the one that makes sense. No hard rules, but private 
>    enough that people won't feel _guilty_ about reporting problems. Right 
>    now I sometimes get private email from people who don't want to point
>    out some local DoS or similar, and that can certainly get lost in the
>    flow.

And also not passed on to vendors and other folks which is a pita and
this would fix
> 
>  - _short_ embargo, for kernel-only. I obviously believe that vendor-sec 
>    is whoring itself for security firms and vendors. I believe there would 
>    be a place for something with stricter rules on disclosure.

Seems these two could be the same list with a bit of respect for users
wishes and common sense.

> It's not a black-and-white thing. I refuse to believe that most security 
> problems are found by people without any morals. I believe that somewhere 
> in the middle is where most people feel most comfortable.

Seems sane



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 14:47:04 -0800 (PST)



On Thu, 13 Jan 2005, Alan Cox wrote:
>
> >  - _short_ embargo, for kernel-only. I obviously believe that vendor-sec 
> >    is whoring itself for security firms and vendors. I believe there would 
> >    be a place for something with stricter rules on disclosure.
> 
> Seems these two could be the same list with a bit of respect for users
> wishes and common sense.

Possibly. On the other hand, I can well imagine that the list of
subscribers is different for the two cases. The same way I refuse to have
anything to do with vendor-sec, maybe somebody else refuses to honor even
a five-day rule, but would want to be on the "no rules, but let's be clear
that we're all good guys, not gray or black-hats.

Also, especially with a hard rule, there's just less confusion, I think, 
if the two are separate. Otherwise you'd have to have strict Subject: line 
rules or something - which basically means that they are separate lists 
anyway.

But hey, it's not even clear that both are needed. With a short enough 
disclosure requirement, maybe people feel like the "five-day rule, 
possible explicitly _relaxed_ by the original submitter" is sufficient.

			Linus



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 12:28:14 -0800 (PST)




On Wed, 12 Jan 2005, Linus Torvalds wrote:
> 
> 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.

Btw, the only thing I care about is the embargo on the _fix_.

If a bug reporter is a security house, and wants to put a longer embargo
on announcing the bug itself, or on some other aspect of the issue (ie
known exploits etc), and wants to make sure that they get the credit and 
they get to be the first ones to announce the problem, that's fine by me. 

The only thing I really care about is that we can serve the people who
depend on us by giving them source code that is as bug-free and secure as 
we can make it. If that means that we should make the changelogs be a bit 
less verbose because we don't want to steal the thunder from the people 
who found the problem, that's fine.

One of the problems with the embargo thing has been exactly the fact that
people couldn't even find bugs (or just uglinesses) in the fixes, because
they were kept under wraps until the "proper date". 

			Linus



From: Marcelo Tosatti [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 16:03:40 -0200

On Wed, Jan 12, 2005 at 12:28:14PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 12 Jan 2005, Linus Torvalds wrote:
> > 
> > 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.
> 
> Btw, the only thing I care about is the embargo on the _fix_.
> 
> If a bug reporter is a security house, and wants to put a longer embargo
> on announcing the bug itself, or on some other aspect of the issue (ie
> known exploits etc), and wants to make sure that they get the credit and 
> they get to be the first ones to announce the problem, that's fine by me. 
> 
> The only thing I really care about is that we can serve the people who
> depend on us by giving them source code that is as bug-free and secure as 
> we can make it. If that means that we should make the changelogs be a bit 
> less verbose because we don't want to steal the thunder from the people 
> who found the problem, that's fine.

I'm not a big fan of hiding security fixes - having a defined and clear 
list of security issues is important. Moreover, the code itself is verbose
enough for some people. 

If you release the code earlier than the embargo date, even with "non verbose 
changelogs", to best serve the people who depend on us by giving them source 
code that is as bug-free and secure as possible, you make the issue public. 

IMO the best thing is to be very verbose about security problems - giving 
credit to the people who deserve it accordingly (not stealing the thunder
from the discovers, but rather making more visible on the changelog who
they are).

The KSO (Kernel Security Officer, the new buzzword on the block) has to 
control the embargo date and be strict about it.

> One of the problems with the embargo thing has been exactly the fact that
> people couldn't even find bugs (or just uglinesses) in the fixes, because
> they were kept under wraps until the "proper date". 

Exactly, and keeping under wraps means "obscure, unclear list of security issues".
We want the other way around.


From: Dave Jones [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 15:53:50 -0500

On Wed, Jan 12, 2005 at 12:00:52PM -0800, Linus Torvalds 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"
 > 
 > 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".

Who would be on the kernel security list if it's to be invite only ?
Is this just going to be a handful of folks, or do you foresee it
being the same kernel folks that are currently on vendor-sec ?

My first thought was 'Chris will forward the output of [email blocked]
to vendor-sec, and we'll get a chance to get updates built'. But you
seem dead-set against any form of delayed disclosure, which has the
effect of catching us all with our pants down when you push out
a new kernel fixing a hole and we don't have updates ready.

At this time, those with bad intents rub their hands with glee
0wning boxes at will whilst those of us responsible for vendor

kernels run like headless chickens trying to get updates out,
which can be a pain the ass if $vendor is supporting some ancient
release which is afflicted by the same bug.

If you turned the current model upsidedown and vendor-sec learned
about issues from [email blocked] a few days before it'd at
least give us *some* time, as opposed to just springing stuff
on us without warning.

Thoughts?

		Dave



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 18:09:31 -0800 (PST)



On Wed, 12 Jan 2005, Dave Jones wrote:
> 
> Who would be on the kernel security list if it's to be invite only ?
> Is this just going to be a handful of folks, or do you foresee it
> being the same kernel folks that are currently on vendor-sec ?

I'd assume that it's as many as possible. The current vendor-sec kernel
people _plus_ anybody else who wants to.

> My first thought was 'Chris will forward the output of [email blocked]
> to vendor-sec, and we'll get a chance to get updates built'. But you
> seem dead-set against any form of delayed disclosure, which has the
> effect of catching us all with our pants down when you push out
> a new kernel fixing a hole and we don't have updates ready.

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 only thing it does is 
allow the vendor to point fingers and say "hey, we have an update, now 
it's your problem".

In reality, the user usually needs to have the update available _before_
the disclosure anyway. Preferably by _months_, not minutes.

So I think the whole vendor-sec thing is not helping users at all, it's 
purely a "vendor embarassment" thing. 

> If you turned the current model upsidedown and vendor-sec learned
> about issues from [email blocked] a few days before it'd at
> least give us *some* time, as opposed to just springing stuff
> on us without warning.

I think kernel bugs should be fixed as soon as humanly possible, and _any_
delay is basically just about making excuses. And that means that as many
people as possible should know about the problem as early as possible,
because any closed list (or even just anybody sending a message to me
personally) just increases the risk of the thing getting lost and delayed
for the wrong reasons.

So I'd not personally mind some _totally_ open list. No embargo at all, no 
limits on who reads it. The more, the merrier. However, I think my 
personal preference is pretty extreme in one end, and I also think that 
vendor-sec is extreme in the other. So there is probably some middle 
ground.

Will it make everybody happy? Hell no. Nothing like that exists. Which is 
why I'm willing to live with an embargo as long as I don't feel like I'm 
being toyed with.

And hey, vendor-sec works. I feel like vendor-sec just toys with me, which
is why I refuse to have anything to do with it, but it's entirely possible
that the best solution is to just ignore my wishes. That's OK. I'm ok with
it, vendor-sec is ok with it, nobody is _happy_ with it, but it's another
compromise. Agreeing to disagree is fine too, after all.

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.  
Whatever. I happen to believe in openness, and vendor-sec does not. It's
that simple.

But if we're seriously looking for a middle ground between my "it should 
be open" and vendor-sec "it should be totally closed", that's where my 
suggestions come in. Whether people _want_ to look for a middle ground is 
the thing to ask first..

For example, having an arbitrarily long embargo on actual known exploit
code is fine with me. I don't care. If I have to promise to never ever
disclose an exploit code in order to see it, I'm fine with that - but I
refuse to delay the _fix_ by more than a few days, and even that "few
days" goes out the window if somebody else has knowingly delayed giving
the fix or problem to me in the first place.

This is not just about sw security, btw. I refuse to sign NDA's on hw 
errata too. Same deal - it may mean that I get to know about the problem 
later, but it also means that I don't have to feel guilty about knowing of 
a problem and being unable to fix it. And it means that people can trust 
_me_ personally.

		Linus



From: Andrew Morton [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 18:28:38 -0800

Linus Torvalds [email blocked] 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.
> ...
> 
>  So I think the whole vendor-sec thing is not helping users at all, it's 
>  purely a "vendor embarassment" thing. 

That sounds a bit over-the-top to me, sorry.

AFAIUI, the vendor requirement is that they have time to have an upgraded
kernel package on their servers when the bug becomes public knowledge.

If correct and reasonable, then what is the best way in which we can
support them in this while promptly upgrading the kernel.org kernel?


Also:

I think we need to be more explicit in separating _types_ of security
problems.  This recent controversy over the RLIM_MEMLOCK DoS is plain
silliness.

Look through the kernel changelogs for the past year - we've fixed a huge
number of "fix oops in foo" and "fix deadlock in bar" and "fix memory leak
in zot".  All of these are of exactly the same severity as the rlimit bug,
and nobody cares, nobody is hurt.

The fuss over the rlimit problem occurred simply because some external
organisation chose to make a fuss over it.

IMO, local DoS holes are important mainly because buggy userspace
applications allow remote users to get in and exploit them, and for that
reason we of course need to fix them up.  Even though such an attacker
could cripple the machine without exploiting such a hole.

For the above reasons I see no need to delay publication of local DoS holes
at all.  The only thing for which we need to provide special processing is
privilege escalation bugs.

Or am I missing something?



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Wed, 12 Jan 2005 18:51:36 -0800 (PST)



On Wed, 12 Jan 2005, Andrew Morton wrote:
> 
> That sounds a bit over-the-top to me, sorry.

Maybe a bit pointed, but the question is: would a user perhaps want to 
know about a security fix a month earlier (knowing that bad people might 
guess at it too), or want the security fix a month later (knowing that the 
bad guys may well have known about the problem all the time _anyway_)?

Being public is different from being known about. If vendor-sec knows 
about it, I don't find it at all unbelievable that some spam-virus writer 
might know about it too.

>  All of these are of exactly the same severity as the rlimit bug,
> and nobody cares, nobody is hurt.

The fact is, 99% of the time, nobody really does care. 

> The fuss over the rlimit problem occurred simply because some external
> organisation chose to make a fuss over it.

I agree. And if i thad been out in the open all the time, the fuss simply 
would not have been there.

I'm a big believer in _total_ openness. Accept the fact that bugs will 
happen. Be open about them, and fix them as soon as possible. None of this 
cloak-and-dagger stuff.

		Linus



From: Linus Torvalds [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 11:46:10 -0800 (PST)



On Thu, 13 Jan 2005, John Richard Moser wrote:
> 
> > So all security issues are about balancing cost vs gain. I'm convinced
> > that the gain from openness is higher than the cost. Others will disagree.  
> 
> Yes.  Nobody code audits your binaries.  You need source code to do
> source code auditing.  :)

Oh, it's very clear that some exploits have definitely been written by
looking at the source code with automated tools or by instrumenting
things, and that the exploits would likely have never been found without
source code. That's fine. We just have higher requirements in the open
source community.

And I do think that the same is true for being open about security
advisories: I think that to offset an open security list, we'd have to
then have more "best practices" than a vendor-sec-type closed security
list might need. I think it would be worth it.

			Linus



From: Alan Cox [email blocked]
Subject: Re: thoughts on kernel security issues
Date: 	Thu, 13 Jan 2005 15:36:33 +0000

On Iau, 2005-01-13 at 03:53, Marek Habersack wrote:
> That might be, but note one thing: not everybody runs vendor kernels (for various
> reasons). Now see what happens when the super-secret vulnerability (with
> vendor fixes) is described in an advisory. A person managing a park of machines 
> (let's say 100) with custom, non-vendor, kernels suddenly finds out that they 
> have a buggy kernel and 100 machines to upgrade while the exploit and the

Those running 2.4 non-vendor kernels are just fine because Marcelo
chooses to work with vendor-sec while Linus chooses not to. I choose to
work with vendor-sec so generally the -ac tree is also fairly prompt on
fixing things. 

Given that base 2.6 kernels are shipped by Linus with known unfixed
security holes anyone trying to use them really should be doing some
careful thinking. In truth no 2.6 released kernel is suitable for
anything but beta testing until you add a few patches anyway. 

2.6.9 for example went out with known holes and broken AX.25 (known) 
2.6.10 went out with the known holes mostly fixed but memory corrupting
bugs, AX.25 still broken and the wrong fix applied for the smb holes so
SMB doesn't work on it

I still think the 2.6 model works well because its making very good
progress and then others are doing testing and quality management on it.
Linus is doing the stuff he is good at and other people are doing the
stuff he doesn't.

That change of model changes the security model too however.



From: Chris Wright [email blocked]
Subject: security contact draft
Date: 	Thu, 13 Jan 2005 12:55:03 -0800

To keep the conversation concrete, here's a pretty rough stab at
documenting the policy.

 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.

 1) Contact

 The Linux kernel security contact is $CONTACTADDR.  This is a private
 list of security officers who will help verify the bug report and develop
 and release a fix.  It is possible that the security officers will bring
 in extra help from area maintainers to understand and fix the security
 vulnerability.

 It is preferred that mail sent to the security contact is encrypted
 with $PUBKEY.

 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
 REPORTING-BUGS if you are unclear about what information is helpful.
 Any exploit code is very helpful and will not be released without
 consent from the reporter unless it's already been made public.

 2) Disclosure

 The goal of the kernel security contact is to work with the bug submitter
 to bug resolution as well as disclosure.  We prefer to fully disclose
 the bug as soon as possible.  It is reasonable to delay disclosure when
 the bug or the fix is not yet fully understood, the solution is not
 well-tested or for vendor coordination.  However, we expect these delays
 to be short, measurable in days, not weeks or months.  As a basic default
 policy, we expect report to disclosure to be on the order of $NUMDAYS.



From: Alan Cox [email blocked]
Subject: Re: security contact draft
Date: 	Thu, 13 Jan 2005 20:10:58 +0000

On Iau, 2005-01-13 at 20:55, Chris Wright wrote:
> To keep the conversation concrete, here's a pretty rough stab at
> documenting the policy.

It's not documenting the stuff Linus seems to be talking about which is
a public list ? Or does Linus want both ?

>  It is preferred that mail sent to the security contact is encrypted
>  with $PUBKEY.

https:// and bugs.kernel.org ? You can make bugzilla autoprivate
security bugs and alert people.

>  well-tested or for vendor coordination.  However, we expect these delays
>  to be short, measurable in days, not weeks or months.  As a basic default
>  policy, we expect report to disclosure to be on the order of $NUMDAYS.

Sounds good. $NUMDAYS is going to require some debate. My gut feeling is
14 days is probably the right kind of target for hard stuff remembering
how long it takes to run QA on an enterprise grade kernel. If it gets
too short then vendors are going to disclose elsewhere for their own
findings and only to this list when they are all ready anyway which
takes us back to square one.

And many are probably a lot less - those nobody is going to rush out and
build new vendor kernels for, or those that prove to be non serious can
probably get bumped to the public list by the security officer within a
day or two.

Alan



From: Linus Torvalds [email blocked]
Subject: Re: security contact draft
Date: 	Thu, 13 Jan 2005 13:31:19 -0800 (PST)



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.

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.

			Linus



From: Marcelo Tosatti [email blocked]
Subject: Re: security contact draft
Date: 	Thu, 13 Jan 2005 17:28:14 -0200

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.



From: Florian Weimer [email blocked]
Subject: Re: security contact draft
Date: 	Thu, 13 Jan 2005 22:43:29 +0100

* Chris Wright:

> To keep the conversation concrete, here's a pretty rough stab at


> documenting the policy.

Looks fine.  Maybe you can add the following section?

  3) Non-disclosure agreements

  The Linux kernel security contact is not a formal body and therefore
  unable to enter any non-disclosure agreements.

UNIRAS and probably others require NDAs from affected software vendors
before they share vulnerability information.  It makes things easier
if you state upfront that you won't play such games.



From: Chris Wright [email blocked]
Subject: Re: security contact draft
Date: 	Thu, 13 Jan 2005 14:12:29 -0800

* Florian Weimer [email blocked] wrote:
> * Chris Wright:
> 
> > To keep the conversation concrete, here's a pretty rough stab at
> > documenting the policy.
> 
> Looks fine.  Maybe you can add the following section?
> 
>   3) Non-disclosure agreements
> 
>   The Linux kernel security contact is not a formal body and therefore
>   unable to enter any non-disclosure agreements.
> 
> UNIRAS and probably others require NDAs from affected software vendors
> before they share vulnerability information.  It makes things easier
> if you state upfront that you won't play such games.

Fair point, I can add that easily.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

• Archive of above thread [thread 1 [thread 2]
• KernelTrap interview with Marcelo Tosatti
• KernelTrap interview with Alan Cox
• KernelTrap interview with Dave Jones
• KernelTrap interview with Andrew Morton