Re: security contact draft

Re: security contact draft

[Marcelo Tosatti]

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.

Re: security contact draft

[Alan Cox]

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

security contact draft

[Chris Wright]

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.

Re: security contact draft

[Linus Torvalds]

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

Re: security contact draft

[Florian Weimer]

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

Re: security contact draft

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> 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 ?

I got the impression that Linus was in favor of the private one,
despite his own leanings to absolute openness.  I think a public one
(lkml notwithstanding) would be great for advisory announcements.

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

Yeah, I had thought about that too.  Not a real bugzilla fan, but I'm
not tied to any particular method here.

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

Yup, I think the severity and ease of exploit are part of the discussion
around disclosure timeframe.

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

Re: security contact draft

[Chris Wright]

* Florian Weimer (fw@deneb.enyo.de) 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

Re: security contact draft

[Alan Cox]

On Iau, 2005-01-13 at 22:12, Chris Wright wrote:
> > 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.

Is it worth adding the stipulation up front about who sets release dates
and within what limit as well >

Re: security contact draft

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Iau, 2005-01-13 at 22:12, Chris Wright wrote:
> > > 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.
> 
> Is it worth adding the stipulation up front about who sets release dates
> and within what limit as well >

Guess it's an open question.  Do you agree with these basics bits?

 - no guarantee
 - attempt to work with reporter
 - attempt to work with vendors
 - goal of timely release
 - retain final say
 - within immediate to few weeks
 
Hard to put real time on it.

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

Re: security contact draft

[Alan Cox]

On Sad, 2005-01-15 at 02:43, Chris Wright wrote:
> Guess it's an open question.  Do you agree with these basics bits?
> 
>  - no guarantee
>  - attempt to work with reporter
>  - attempt to work with vendors
>  - goal of timely release
>  - retain final say
>  - within immediate to few weeks
>  
> Hard to put real time on it.

Its emphasising "release date set by linux-security not reporter" rather
than length - although length guidance is good.

security contact draft2 (was Re: security contact draft)

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Sad, 2005-01-15 at 02:43, Chris Wright wrote:
> > Guess it's an open question.  Do you agree with these basics bits?
> > 
> >  - no guarantee
> >  - attempt to work with reporter
> >  - attempt to work with vendors
> >  - goal of timely release
> >  - retain final say
> >  - within immediate to few weeks
> >  
> > Hard to put real time on it.
> 
> Its emphasising "release date set by linux-security not reporter" rather
> than length - although length guidance is good.

Minor changes to capture this.

thanks,
-chris

 DRAFT

 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.  Please report security bugs to the
 Linux kernel security team.

 1) Contact

 The Linux kernel security team can be contacted by email at
 $CONTACTADR.  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 team will bring in extra help from
 area maintainers to understand and fix the security vulnerability.

 It is preferred that mail sent to the security team 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 has already been made public.

 2) Disclosure

 The goal of the Linux kernel security team 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.
 A disclosure date is negotiated by the security team working with the
 bug submitter as well as vendors.  However, the kernel security team
 holds the final say when setting a disclosure date.  The timeframe for
 disclosure is from immediate (esp. if it's already publically known)
 to a few weeks.  As a basic default policy, we expect report date to
 disclosure date to be on the order of 7 days.

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

Re: security contact draft2 (was Re: security contact draft)

[Horst von Brand]

Chris Wright <chrisw@osdl.org> said:

[...]

>  DRAFT

[...]

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

Note that $PUBKEY might change, give pointers to the canonical places where
you can get the latest version (latest kernel source?). Perhaps indicate
where to find gpg and a gpg-aware mailer, or steps to encrypt a file and
send that over as an attachment. Need to clarify a mechanism by which they
can get back to you via encripted mail.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: security contact draft

[Patrick Plattes]

hello,

i think security mailing list is a good idea. normally i would prefere a
full open list, but in some cases this could be the right way.

i have an additional idea. maybe it is useful to push the mails on the
list into publc space automaticly after a delay of $NUMDAYS+$MAX -
according to alans idea. with this little feature we could be sure, that
no security report will be 'forgotten'.

this 'public space' could be an open security list where anyone else is
able to comment reports, fixes and bugs.

bye,
patrick

On Thu, Jan 13, 2005 at 12:55:03PM -0800, Chris Wright wrote:
> 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.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: security contact draft

[Chris Wright]

* Patrick Plattes (patrick@erdbeere.net) wrote:
> i think security mailing list is a good idea. normally i would prefere a
> full open list, but in some cases this could be the right way.
> 
> i have an additional idea. maybe it is useful to push the mails on the
> list into publc space automaticly after a delay of $NUMDAYS+$MAX -
> according to alans idea. with this little feature we could be sure, that
> no security report will be 'forgotten'.
> 
> this 'public space' could be an open security list where anyone else is
> able to comment reports, fixes and bugs.

We had actually discussed this.  It's mainly a difficulty in managing
such an idea, nobody was opposed to it.

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