Thanks, applied to master.
On Tue, Mar 29, 2016 at 12:27:24PM -0600, Ryan Moats wrote: > Yep, looks sensible... > > Acked-by: Ryan Moats <rmo...@us.ibm.com> > > "dev" <dev-boun...@openvswitch.org> wrote on 03/29/2016 01:07:53 PM: > > > From: Ben Pfaff <b...@ovn.org> > > To: dev@openvswitch.org > > Cc: Ben Pfaff <b...@ovn.org> > > Date: 03/29/2016 01:09 PM > > Subject: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details. > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > Signed-off-by: Ben Pfaff <b...@ovn.org> > > --- > > SECURITY.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ > > ++++++++--- > > 1 file changed, 100 insertions(+), 4 deletions(-) > > > > diff --git a/SECURITY.md b/SECURITY.md > > index 08a6ed8..33b85b5 100644 > > --- a/SECURITY.md > > +++ b/SECURITY.md > > @@ -101,16 +101,112 @@ determines that it is not a realistic > vulnerability. > > Step 3a: Document > > ---------------- > > > > -The security team develops a security advisory document. The document > > -credits the reporter and describes the vulnerability, including all of > > -the relevant information from the assessment in step 2. The security > > +The security team develops a security advisory document. The security > > team may, at its discretion, include the reporter (via "CC") in > > developing the security advisory document, but in any case should > > accept feedback from the reporter before finalizing the document. > > - > > When the document is final, the security team should obtain a CVE for > > the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). > > > > +The document credits the reporter and describes the vulnerability, > > +including all of the relevant information from the assessment in step > > +2. Suitable sections for the document include: > > + > > + * Title: The CVE identifier, a short description of the > > + vulnerability. The title should mention Open vSwitch. > > + > > + In email, the title becomes the subject. Pre-release advisories > > + are often passed around in encrypted email, which have plaintext > > + subjects, so the title should not be too specific. > > + > > + * Description: A few paragraphs describing the general > > + characteristics of the vulnerability, including the versions of > > + Open vSwitch that are vulnerable, the kind of attack that > > + exposes the vulnerability, and potential consequences of the > > + attack. > > + > > + The description should re-state the CVE identifier, in case the > > + subject is lost when an advisory is sent over email. > > + > > + * Mitigation: How an Open vSwitch administrator can minimize the > > + potential for exploitation of the vulnerability, before applying > > + a fix. If no mitigation is possible or recommended, explain > > + why, to reduce the chance that at-risk users believe they are > > + not at risk. > > + > > + * Fix: Describe how to fix the vulnerability, perhaps in terms of > > + applying a source patch. The patch or patches themselves, if > > + included in the email, should be at the very end of the advisory > > + to reduce the risk that a reader would stop reading at this > > + point. > > + > > + * Recommendation: A concise description of the security team's > > + recommendation to users. > > + > > + * Acknowledgments: Thank the reporters. > > + > > + * Vulnerability Check: A step-by-step procedure by which a user > > + can determine whether an installed copy of Open vSwitch is > > + vulnerable. > > + > > + The procedure should clearly describe how to interpret the > > + results, including expected results in vulnerable and > > + not-vulnerable cases. Thus, procedures that produce clear and > > + easily distinguished results are preferred. > > + > > + The procedure should assume as little understanding of Open > > + vSwitch as possible, to make it more likely that a competent > > + administrator who does not specialize in Open vSwitch can > > + perform it successfully. > > + > > + The procedure should have minimal dependencies on tools that are > > + not widely installed. > > + > > + Given a choice, the procedure should be one that takes at least > > + some work to turn into a useful exploit. For example, a > > + procedure based on "ovs-appctl" commands, which require local > > + administrator access, is preferred to one that sends test > > + packets to a machine, which only requires network connectivity. > > + > > + The section should say which operating systems it is designed > > + for. If the procedure is likely to be specific to particular > > + architectures (e.g. x86-64, i386), it should state on which ones > > + it has been tested. > > + > > + This section should state the risks of the procedure. For > > + example. if it can crash Open vSwitch or disrupt packet > > + forwarding, say so. > > + > > + It is more useful to explain how to check an installed and > > + running Open vSwitch than one built locally from source, but if > > + it is easy to use the procedure from a sandbox environment, it > > + can be helpful to explain how to do so. > > + > > + * Patch: If a patch or patches are available, and it is practical > > + to include them in the email, put them at the end. Format them > > + as described in CONTRIBUTING.md, that is, as output by "git > > + format-patch". > > + > > + The patch subjects should include the version for which they are > > + suited, e.g. "[PATCH branch-2.3]" for a patch against Open > > + vSwitch 2.3.x. If there are multiple patches for multiple > > + versions of Open vSwitch, put them in separate sections with > > + clear titles. > > + > > + Multiple patches for a single version of Open vSwitch, that must > > + be stacked on top of each other to fix a single vulnerability, > > + are undesirable because users are less likely to apply all of > > + them correctly and in the correct order. > > + > > + Each patch should include a Vulnerability tag with the CVE > > + identifier, a Reported-by tag or tags to credit the reporters, > > + and a Signed-off-by tag to acknowledge the Developer's > > + Certificate of Origin. It should also include other appropriate > > + tags, such as Acked-by tags obtained during review. > > + > > +CVE-2016-2074 is an example advisory document, available at: > > + http://openvswitch.org/pipermail/announce/2016-March/000082.html > > + > > > > Step 3b: Fix > > ------------ > > -- > > 2.1.3 > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
