* security contact draft @ 2005-01-13 20:55 Chris Wright 2005-01-13 20:10 ` Alan Cox ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Chris Wright @ 2005-01-13 20:55 UTC (permalink / raw) To: akpm, torvalds, alan, marcelo.tosatti; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 20:55 security contact draft Chris Wright @ 2005-01-13 20:10 ` Alan Cox 2005-01-13 21:31 ` Linus Torvalds 2005-01-13 22:02 ` Chris Wright 2005-01-13 21:43 ` Florian Weimer 2005-02-03 14:28 ` security contact draft Patrick Plattes 2 siblings, 2 replies; 14+ messages in thread From: Alan Cox @ 2005-01-13 20:10 UTC (permalink / raw) To: Chris Wright; +Cc: akpm, torvalds, marcelo.tosatti, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 20:10 ` Alan Cox @ 2005-01-13 21:31 ` Linus Torvalds 2005-01-13 19:28 ` Marcelo Tosatti 2005-01-13 22:02 ` Chris Wright 1 sibling, 1 reply; 14+ messages in thread From: Linus Torvalds @ 2005-01-13 21:31 UTC (permalink / raw) To: Alan Cox; +Cc: Chris Wright, akpm, marcelo.tosatti, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 21:31 ` Linus Torvalds @ 2005-01-13 19:28 ` Marcelo Tosatti 0 siblings, 0 replies; 14+ messages in thread From: Marcelo Tosatti @ 2005-01-13 19:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alan Cox, Chris Wright, akpm, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 20:10 ` Alan Cox 2005-01-13 21:31 ` Linus Torvalds @ 2005-01-13 22:02 ` Chris Wright 1 sibling, 0 replies; 14+ messages in thread From: Chris Wright @ 2005-01-13 22:02 UTC (permalink / raw) To: Alan Cox Cc: Chris Wright, akpm, torvalds, marcelo.tosatti, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 20:55 security contact draft Chris Wright 2005-01-13 20:10 ` Alan Cox @ 2005-01-13 21:43 ` Florian Weimer 2005-01-13 22:12 ` Chris Wright 2005-02-03 14:28 ` security contact draft Patrick Plattes 2 siblings, 1 reply; 14+ messages in thread From: Florian Weimer @ 2005-01-13 21:43 UTC (permalink / raw) To: Chris Wright; +Cc: linux-kernel * 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 21:43 ` Florian Weimer @ 2005-01-13 22:12 ` Chris Wright 2005-01-15 0:33 ` Alan Cox 0 siblings, 1 reply; 14+ messages in thread From: Chris Wright @ 2005-01-13 22:12 UTC (permalink / raw) To: Florian Weimer; +Cc: Chris Wright, linux-kernel * 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 22:12 ` Chris Wright @ 2005-01-15 0:33 ` Alan Cox 2005-01-15 2:43 ` Chris Wright 0 siblings, 1 reply; 14+ messages in thread From: Alan Cox @ 2005-01-15 0:33 UTC (permalink / raw) To: Chris Wright; +Cc: Florian Weimer, Linux Kernel Mailing List 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 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-15 0:33 ` Alan Cox @ 2005-01-15 2:43 ` Chris Wright 2005-01-15 4:00 ` Alan Cox 0 siblings, 1 reply; 14+ messages in thread From: Chris Wright @ 2005-01-15 2:43 UTC (permalink / raw) To: Alan Cox; +Cc: Chris Wright, Florian Weimer, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-15 2:43 ` Chris Wright @ 2005-01-15 4:00 ` Alan Cox 2005-01-18 0:24 ` security contact draft2 (was Re: security contact draft) Chris Wright 0 siblings, 1 reply; 14+ messages in thread From: Alan Cox @ 2005-01-15 4:00 UTC (permalink / raw) To: Chris Wright; +Cc: Florian Weimer, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* security contact draft2 (was Re: security contact draft) 2005-01-15 4:00 ` Alan Cox @ 2005-01-18 0:24 ` Chris Wright 2005-01-18 17:39 ` Horst von Brand 0 siblings, 1 reply; 14+ messages in thread From: Chris Wright @ 2005-01-18 0:24 UTC (permalink / raw) To: Alan Cox; +Cc: Chris Wright, Florian Weimer, Linux Kernel Mailing List * 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft2 (was Re: security contact draft) 2005-01-18 0:24 ` security contact draft2 (was Re: security contact draft) Chris Wright @ 2005-01-18 17:39 ` Horst von Brand 0 siblings, 0 replies; 14+ messages in thread From: Horst von Brand @ 2005-01-18 17:39 UTC (permalink / raw) To: Chris Wright; +Cc: Alan Cox, Florian Weimer, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-01-13 20:55 security contact draft Chris Wright 2005-01-13 20:10 ` Alan Cox 2005-01-13 21:43 ` Florian Weimer @ 2005-02-03 14:28 ` Patrick Plattes 2005-02-03 18:08 ` Chris Wright 2 siblings, 1 reply; 14+ messages in thread From: Patrick Plattes @ 2005-02-03 14:28 UTC (permalink / raw) To: Chris Wright; +Cc: linux-kernel 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/ > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: security contact draft 2005-02-03 14:28 ` security contact draft Patrick Plattes @ 2005-02-03 18:08 ` Chris Wright 0 siblings, 0 replies; 14+ messages in thread From: Chris Wright @ 2005-02-03 18:08 UTC (permalink / raw) To: Patrick Plattes; +Cc: Chris Wright, linux-kernel * 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2005-02-03 18:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-13 20:55 security contact draft Chris Wright 2005-01-13 20:10 ` Alan Cox 2005-01-13 21:31 ` Linus Torvalds 2005-01-13 19:28 ` Marcelo Tosatti 2005-01-13 22:02 ` Chris Wright 2005-01-13 21:43 ` Florian Weimer 2005-01-13 22:12 ` Chris Wright 2005-01-15 0:33 ` Alan Cox 2005-01-15 2:43 ` Chris Wright 2005-01-15 4:00 ` Alan Cox 2005-01-18 0:24 ` security contact draft2 (was Re: security contact draft) Chris Wright 2005-01-18 17:39 ` Horst von Brand 2005-02-03 14:28 ` security contact draft Patrick Plattes 2005-02-03 18:08 ` Chris Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).