From patchwork Tue Oct 18 20:03:38 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Finucane X-Patchwork-Id: 683852 X-Patchwork-Delegate: rbryant@redhat.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (archives.nicira.com [96.126.127.54]) by ozlabs.org (Postfix) with ESMTP id 3sz5h33SXPz9s2G for ; Wed, 19 Oct 2016 07:06:58 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=that.guru header.i=@that.guru header.b=kwHe1PBN; dkim-atps=neutral Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id ACF291056A; Tue, 18 Oct 2016 13:06:57 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx3v3.cudamail.com (mx3.cudamail.com [64.34.241.5]) by archives.nicira.com (Postfix) with ESMTPS id 9D08C10547 for ; Tue, 18 Oct 2016 13:06:56 -0700 (PDT) Received: from bar6.cudamail.com (localhost [127.0.0.1]) by mx3v3.cudamail.com (Postfix) with ESMTPS id E9D74162B34 for ; Tue, 18 Oct 2016 14:06:55 -0600 (MDT) X-ASG-Debug-ID: 1476821213-0b3237781b271f0001-byXFYA Received: from mx3-pf1.cudamail.com ([192.168.14.2]) by bar6.cudamail.com with ESMTP id 2dpPIFXs3HW5jKb2 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2016 14:06:53 -0600 (MDT) X-Barracuda-Envelope-From: stephen@that.guru X-Barracuda-RBL-Trusted-Forwarder: 192.168.14.2 Received: from unknown (HELO brown.birch.relay.mailchannels.net) (23.83.209.23) by mx3-pf1.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 18 Oct 2016 20:06:52 -0000 Received-SPF: none (mx3-pf1.cudamail.com: domain at that.guru does not designate permitted sender hosts) X-Barracuda-Apparent-Source-IP: 23.83.209.23 X-Barracuda-RBL-IP: 23.83.209.23 X-Sender-Id: mxroute|x-authuser|stephen@that.guru Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 39EDE1279E8 for ; Tue, 18 Oct 2016 20:06:51 +0000 (UTC) Received: from one.mxroute.com (ip-10-220-3-24.us-west-2.compute.internal [10.220.3.24]) by relay.mailchannels.net (Postfix) with ESMTPA id 8E13E127470 for ; Tue, 18 Oct 2016 20:06:48 +0000 (UTC) X-Sender-Id: mxroute|x-authuser|stephen@that.guru Received: from one.mxroute.com ([UNAVAILABLE]. [10.102.194.57]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.8); Tue, 18 Oct 2016 20:06:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: mxroute|x-authuser|stephen@that.guru X-MailChannels-Auth-Id: mxroute X-MC-Loop-Signature: 1476821208916:850888068 X-MC-Ingress-Time: 1476821208916 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=that.guru; s=default; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JgvmFG4rGequ2Y5bE1JfU6UnoGKeQK7yl3TqTkWsiDI=; b=kwHe1PBNSqN3fJEYEENCg+N+Uq qmuTDclSLe5HIf3k873k6+qTTyvnkjFVjju45Z8uZi+O0KsH1XPi2fCCJlvkKWdRrIdy0Z08WOIDZ DU2ZSAJKqdFBx78nHylFcI/fCpWfIdtdNXu7IjVyFOuvv2Cly4uWF8p2cAULvUX4FU7k3FVpX8foa JWYLBp5wQQDIEqqehjoDb+vDQGxd6uRmjm5whOsB+U/aNZ+63e0qtyPkMQMN8shwSqu3fiZNDGEzz SOpIHfzexiwaA/OnEYJ3wrwv8GxZ3upTMMpbkvPKbC/Pl1LVA+wjv5uDJ/cIROwFFgXcJKpzqCTX1 lnEC08CA==; X-CudaMail-Envelope-Sender: stephen@that.guru From: Stephen Finucane To: dev@openvswitch.org X-CudaMail-MID: CM-V1-1017049305 X-CudaMail-DTE: 101816 X-CudaMail-Originating-IP: 23.83.209.23 Date: Tue, 18 Oct 2016 21:03:38 +0100 X-ASG-Orig-Subj: [##CM-V1-1017049305##][PATCH 08/15] doc: Convert SECURITY to rST Message-Id: <1476821025-4915-9-git-send-email-stephen@that.guru> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1476821025-4915-1-git-send-email-stephen@that.guru> References: <1476821025-4915-1-git-send-email-stephen@that.guru> X-OutGoing-Spam-Status: No, score=-9.2 X-AuthUser: stephen@that.guru X-GBUdb-Analysis: 0, 23.83.209.23, Ugly c=0.303425 p=-0.0526316 Source Normal X-MessageSniffer-Rules: 0-0-0-30910-c X-Barracuda-Connect: UNKNOWN[192.168.14.2] X-Barracuda-Start-Time: 1476821213 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.10 X-Barracuda-Spam-Status: No, SCORE=1.10 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests=BSF_SC0_MV0713, BSF_SC5_MJ1963, DKIM_SIGNED, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.33831 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC0_MV0713 Custom rule MV0713 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Subject: [ovs-dev] [PATCH 08/15] doc: Convert SECURITY to rST X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" This is a top-level document, so plain old rST is preferred. Signed-off-by: Stephen Finucane --- Makefile.am | 2 +- REPORTING-BUGS.rst | 2 +- SECURITY.md => SECURITY.rst | 198 +++++++++++++++++++++----------------------- 3 files changed, 95 insertions(+), 107 deletions(-) rename SECURITY.md => SECURITY.rst (55%) diff --git a/Makefile.am b/Makefile.am index 9373a04..9be391b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -93,7 +93,7 @@ docs = \ README-lisp.md \ README-native-tunneling.md \ REPORTING-BUGS.rst \ - SECURITY.md \ + SECURITY.rst \ WHY-OVS.rst EXTRA_DIST = \ $(docs) \ diff --git a/REPORTING-BUGS.rst b/REPORTING-BUGS.rst index 73e0df3..85b60ea 100644 --- a/REPORTING-BUGS.rst +++ b/REPORTING-BUGS.rst @@ -31,7 +31,7 @@ they can be fixed as quickly as possible. Please report bugs by sending email to bugs@openvswitch.org. -For reporting security vulnerabilities, please read SECURITY.md. +For reporting security vulnerabilities, please read SECURITY.rst. The most important parts of your bug report are the following: diff --git a/SECURITY.md b/SECURITY.rst similarity index 55% rename from SECURITY.md rename to SECURITY.rst index 4cc4ed6..31155a5 100644 --- a/SECURITY.md +++ b/SECURITY.rst @@ -1,23 +1,22 @@ +================ 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. +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. +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? ------------------------ @@ -25,92 +24,87 @@ What is a vulnerability? All vulnerabilities are bugs, but not every bug is a vulnerability. Vulnerabilities compromise one or more of: - * Confidentiality (personal or corporate confidential data). - * Integrity (trustworthiness and correctness). - * Availability (uptime and service). +* Confidentiality (personal or corporate confidential data). + +* Integrity (trustworthiness and correctness). -Here are some examples of vulnerabilities to which one would expect to -apply this process: +* Availability (uptime and service). - * A crafted packet that causes a kernel or userspace crash - (Availability). +Here are some examples of vulnerabilities to which one would expect to apply +this process: - * A flow translation bug that misforwards traffic in a way likely - to hop over security boundaries (Integrity). +* A crafted packet that causes a kernel or userspace crash (Availability). - * An OpenFlow protocol bug that allows a controller to read - arbitrary files from the file system (Confidentiality). +* A flow translation bug that misforwards traffic in a way likely to hop over + security boundaries (Integrity). - * Misuse of the OpenSSL library that allows bypassing certificate - checks (Integrity). +* An OpenFlow protocol bug that allows a controller to read arbitrary files + from the file system (Confidentiality). - * A bug (memory corruption, overflow, ...) that allows one to - modify the behaviour of OVS through external configuration - interfaces such as OVSDB (Integrity). +* Misuse of the OpenSSL library that allows bypassing certificate checks + (Integrity). - * Privileged information is exposed to unprivileged users - (Confidentiality). +* A bug (memory corruption, overflow, ...) that allows one to modify the + behaviour of OVS through external configuration interfaces such as OVSDB + (Integrity). -If in doubt, please do use the vulnerability management process. At -worst, the response will be to report the bug through the usual -channels. +* Privileged information is exposed to unprivileged users (Confidentiality). +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. +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.rst, where relevant. +Consider reporting the information mentioned in `REPORTING-BUGS.rst +`, where relevant. -Reporters may ask for a GPG key while initiating contact with the -security team to deliver more sensitive reports. +Reporters may ask for a GPG key while initiating contact with the security team +to deliver more sensitive reports. 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. - +Handling of vulnerabilities that affect both the Open vSwitch tree and the +upstream Linux kernel should be reported through both processes. 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 security team should discuss the vulnerability. The reporter should be +included in the discussion (via "CC") to an appropriate degree. -The treatment of the vulnerability could end here if the team -determines that it is not a realistic vulnerability. +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 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 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: +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. @@ -205,58 +199,54 @@ including all of the relevant information from the assessment in step 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 - +http://openvswitch.org/pipermail/announce/2016-March/000082.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 must agree to maintain confidentiality. - +The security team develops and obtains (private) reviews for patches that fix +the vulnerability. If necessary, the security team pulls in additional +developers, who must agree to maintain confidentiality. Step 4: Embargoed Disclosure ---------------------------- -The security advisory and patches are sent to downstream stakeholders, -with an embargo date and time set from the time sent. Downstream -stakeholders are expected not to deploy or disclose patches until -the embargo is passed. +The security advisory and patches are sent to downstream stakeholders, with an +embargo date and time set from the time sent. Downstream stakeholders are +expected not to deploy or disclose patches until the embargo is passed. -A disclosure date is negotiated by the security team working with the -bug submitter as well as vendors. However, the Open vSwitch security -team holds the final say when setting a disclosure date. The timeframe -for disclosure is from immediate (esp. if it's already publicly known) -to a few weeks. As a basic default policy, we expect report date to -disclosure date to be 10 to 15 business days. +A disclosure date is negotiated by the security team working with the bug +submitter as well as vendors. However, the Open vSwitch security team holds the +final say when setting a disclosure date. The timeframe for disclosure is from +immediate (esp. if it's already publicly known) to a few weeks. As a basic +default policy, we expect report date to disclosure date to be 10 to 15 +business days. -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. +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 already public, skip this step. - Step 5: Public 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. +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. -When the patch is applied to LTS (long-term support) branches, a new -version should be released. +When the patch is applied to LTS (long-term support) branches, a new version +should be released. -The security advisory should be GPG-signed by a security team member -with a key that is in a public web of trust. +The security advisory should be GPG-signed by a security team member with a key +that is in a public web of trust. +.. _contact: Contact ======= @@ -266,5 +256,3 @@ security@openvswitch.org Report problems with this document to the ovs-bugs mailing list: bugs@openvswitch.org - -Visit http://openvswitch.org/ to learn more about Open vSwitch.