SECURITY: New document describing proposed security process for OVS.

Open vSwitch needs some kind of process for handling vulnerabilities.  So
far, we've been pretty lucky that way, but it can't last forever, and I
think we'll be better off if we have at least the outline of an established
process whenever a significant vulnerability comes along.  Here's my draft
of a process based on the documentation of the OpenStack process at
https://wiki.openstack.org/wiki/Vulnerability_Management.

I don't have a lot of experience with this kind of thing myself, so I'd
appreciate critical review from anyone who does.

Signed-off-by: Ben Pfaff <[email protected]>
Reviewed-by: Flavio Leitner <[email protected]>
Acked-by: Justin Pettit <[email protected]>
Acked-by: Thomas Graf <[email protected]>

Makefile.am

@@ -1,4 +1,4 @@
-# Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
+# Copyright (C) 2007-2015 Nicira, Inc.
 #
 # Copying and distribution of this file, with or without modification,
 # are permitted in any medium without royalty provided the copyright
@@ -89,6 +89,7 @@ docs = \
 	README-lisp.md \
 	README-native-tunneling.md \
 	REPORTING-BUGS.md \
+	SECURITY.md \
 	TODO.md \
 	WHY-OVS.md
 EXTRA_DIST = \

REPORTING-BUGS.md

@@ -7,6 +7,8 @@ bugs so as to ensure that they can be fixed as quickly as possible.
 
 Please report bugs by sending email to [email protected].  
 
+For reporting security vulnerabilities, please read SECURITY.md.
+
 The most important parts of your bug report are the following:
 
   * What you did that make the problem appear.

SECURITY.md

@@ -0,0 +1,154 @@
+Security Process
+================
+
+This is a proposed security vulnerability reporting and handling
+process for Open vSwitch.  It is based on the OpenStack vulnerability
+management process described at
+https://wiki.openstack.org/wiki/Vulnerability_Management.
+
+The OVS security team coordinates vulnerability management using the
+ovs-security mailing list.  Membership in the security team and
+subscription to its mailing list consists of a small number of
+trustworthy people, as determined by rough consensus of the Open
+vSwitch committers on the ovs-committers mailing list.  The Open
+vSwitch security team should include Open vSwitch committers, to
+ensure prompt and accurate vulnerability assessments and patch review.
+
+We encourage everyone involved in the security process to GPG-sign
+their emails.  We additionally encourage GPG-encrypting one-on-one
+conversations as part of the security process.
+
+
+What is a vulnerability?
+------------------------
+
+All vulnerabilities are bugs, but not every bug is a vulnerability.
+Here are some examples of vulnerabilities to which one would expect to
+apply this process:
+
+    * A crafted packet that causes a kernel or userspace crash.
+
+    * A flow translation bug that misforwards traffic in a way likely
+      to hop over security boundaries.
+
+    * An OpenFlow protocol bug that allows a controller to read
+      arbitrary files from the file system.
+
+    * Misuse of the OpenSSL library that allows bypassing certificate
+      checks.
+
+    * A bug (memory corruption, overflow, ...) that allows one to
+      modify the behaviour of OVS through external configuration
+      interfaces such as OVSDB.
+
+    * Privileged information is exposed to unprivileged users.
+
+If in doubt, please do use the vulnerability management process.  At
+worst, the response will be to report the bug through the usual
+channels.
+
+
+Step 1: Reception
+-----------------
+
+To report an Open vSwitch vulnerability, send an email to the
+ovs-security mailing list (see "Contact" at the end of this document).
+A security team member should reply to the reporter acknowledging that
+the report has been received.
+
+Please consider reporting the information mentioned in
+REPORTING-BUGS.md, where relevant.
+
+The Linux kernel has its own vulnerability management process:
+https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
+Handling of vulnerabilities that affect both the Open vSwitch tree and
+the upstream Linux kernel should be reported through both processes.
+Please send your report as a single email to both the kernel and OVS
+security teams to allow those teams to most easily coordinate among
+themselves.
+
+
+Step 2: Assessment
+------------------
+
+The security team should discuss the vulnerability.  The reporter
+should be included in the discussion (via "CC") to an appropriate
+degree.
+
+The assessment should determine which Open vSwitch versions are
+affected (e.g. every version, only the latest release, only unreleased
+versions), the privilege required to take advantage of the
+vulnerability (e.g. any network user, any local L2 network user, any
+local system user, connected OpenFlow controllers), the severity of
+the vulnerability, and how the vulnerability may be mitigated (e.g. by
+disabling a feature).
+
+The treatment of the vulnerability could end here if the team
+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
+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).
+
+
+Step 3b: Fix
+------------
+
+Steps 3a and 3b may proceed in parallel.
+
+The security team develops and obtains (private) reviews for patches
+that fix the vulnerability.  If necessary, the security team pulls in
+additional developers, who should be asked to maintain
+confidentiality.
+
+
+Step 4: Embargoed Disclosure
+----------------------------
+
+The security advisory and patches are sent to downstream stakeholders,
+with an embargo date and time set to 3 to 5 business days from the
+time sent.  Downstream stakeholders are expected not to deploy or
+disclose patches until the embargo is passed.
+
+Operating system vendors are obvious downstream stakeholders.  It may
+not be necessary to be too choosy about who to include: any major Open
+vSwitch user who is interested and can be considered trustworthy
+enough could be included.  To become a downstream stakeholder, email
+the ovs-security mailing list.
+
+If the vulnerability is public, skip this step.
+
+
+Step 5: Full Disclosure
+-----------------------
+
+When the embargo expires, push the (reviewed) patches to appropriate
+branches, post the patches to the ovs-dev mailing list (noting that
+they have already been reviewed and applied), post the security
+advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and
+post the security advisory on the Open vSwitch webpage.
+
+The security advisory should be GPG-signed by a security team member
+with a key that is in a public web of trust.
+
+
+Contact 
+=======
+
+Report security vulnerabilities to the ovs-security mailing list:
+[email protected]
+
+Report problems with this document to the ovs-bugs mailing list:
+[email protected]
+
+Visit http://openvswitch.org/ to learn more about Open vSwitch.