Oops, I committed this at the same time you sent your message. Thanks for agreeing (in IRC) to send it as a patch tomorrow.
On Tue, Jan 6, 2015 at 3:21 PM, Flavio Leitner <f...@redhat.com> wrote: > On Tuesday, January 06, 2015 10:22:10 AM Ben Pfaff wrote: >> 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. > > Contributors must agree to respect the confidentiality. > s/should be asked/must agree to/ > >> + >> +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. > > Maybe we could follow the kernel security doc saying that the embargo > date and time is negotiated. > """ > 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 on the order of 3~5 business days. > """ > > I.e.: if the fix is for the kernel, our QA takes more than a few days > to complete. > >> + >> +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. > > The problem I see here is with new users/developer coming to OVS. What > happens is that OVS releases stable version 1.1.1, after that there is a > couple security issues and the advisories are released. Some new > user/developer gets the latest stable 1.1.1 release and run the > vulnerable code. Maybe, for stable branches at least, a minor release > should be done. > > >> + >> +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. >> > > One thing that comes to mind is the history of vendor-sec[1]. Because > the value of the information, the server was compromised and the list is > no longer alive. Perhaps ovs security list should be maintained separated > from everything else, just in case... > > [1] http://en.wikipedia.org/wiki/Vendor-sec > > Thanks! > fbl -- "I don't normally do acked-by's. I think it's my way of avoiding getting blamed when it all blows up." Andrew Morton _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
