------------------------
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 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.
+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 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:
projects / cascardo / ovs.git / blobdiff