------------------------
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).
+
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 crafted packet that causes a kernel or userspace crash
+ (Availability).
* A flow translation bug that misforwards traffic in a way likely
- to hop over security boundaries.
+ to hop over security boundaries (Integrity).
* An OpenFlow protocol bug that allows a controller to read
- arbitrary files from the file system.
+ arbitrary files from the file system (Confidentiality).
* Misuse of the OpenSSL library that allows bypassing certificate
- checks.
+ checks (Integrity).
* A bug (memory corruption, overflow, ...) that allows one to
modify the behaviour of OVS through external configuration
- interfaces such as OVSDB.
+ interfaces such as OVSDB (Integrity).
- * Privileged information is exposed to unprivileged users.
+ * 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
Please consider reporting the information mentioned in
REPORTING-BUGS.md, where relevant.
+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 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.
+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 3~5 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
enough could be included. To become a downstream stakeholder, email
the ovs-security mailing list.
-If the vulnerability is public, skip this step.
+If the vulnerability is already public, skip this step.
-Step 5: Full Disclosure
------------------------
+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
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.
+
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
=======
Report security vulnerabilities to the ovs-security mailing list: