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
