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 <b...@nicira.com>
Reviewed-by: Flavio Leitner <f...@redhat.com>
---
v1->v2:
- Suggest GPG signing and encryption.
- Mention coordination with Linux kernel security process.
- "ovs-users" is actually "ovs-discuss".
- Mention SECURITY.md from REPORTING-BUGS.md.
- Add examples.
---
Makefile.am | 3 +-
REPORTING-BUGS.md | 2 +
SECURITY.md | 154 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 158 insertions(+), 1 deletion(-)
create mode 100644 SECURITY.md
diff --git a/Makefile.am b/Makefile.am
index 46e8610..26528d9 100644
--- a/Makefile.am
+++ b/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 = \
diff --git a/REPORTING-BUGS.md b/REPORTING-BUGS.md
index 4e08cb1..c046af9 100644
--- a/REPORTING-BUGS.md
+++ b/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 b...@openvswitch.org.
+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.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..e1db4cb
--- /dev/null
+++ b/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:
+secur...@openvswitch.org
+
+Report problems with this document to the ovs-bugs mailing list:
+b...@openvswitch.org
+
+Visit http://openvswitch.org/ to learn more about Open vSwitch.
--
2.1.3
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
