]>
Commit | Line | Data |
---|---|---|
f0664242 BP |
1 | Security Process |
2 | ================ | |
3 | ||
4 | This is a proposed security vulnerability reporting and handling | |
5 | process for Open vSwitch. It is based on the OpenStack vulnerability | |
6 | management process described at | |
7 | https://wiki.openstack.org/wiki/Vulnerability_Management. | |
8 | ||
9 | The OVS security team coordinates vulnerability management using the | |
10 | ovs-security mailing list. Membership in the security team and | |
11 | subscription to its mailing list consists of a small number of | |
12 | trustworthy people, as determined by rough consensus of the Open | |
13 | vSwitch committers on the ovs-committers mailing list. The Open | |
14 | vSwitch security team should include Open vSwitch committers, to | |
15 | ensure prompt and accurate vulnerability assessments and patch review. | |
16 | ||
17 | We encourage everyone involved in the security process to GPG-sign | |
18 | their emails. We additionally encourage GPG-encrypting one-on-one | |
19 | conversations as part of the security process. | |
20 | ||
21 | ||
22 | What is a vulnerability? | |
23 | ------------------------ | |
24 | ||
25 | All vulnerabilities are bugs, but not every bug is a vulnerability. | |
b13bfc3c AK |
26 | Vulnerabilities compromise one or more of: |
27 | ||
28 | * Confidentiality (personal or corporate confidential data). | |
29 | * Integrity (trustworthiness and correctness). | |
30 | * Availability (uptime and service). | |
31 | ||
f0664242 BP |
32 | Here are some examples of vulnerabilities to which one would expect to |
33 | apply this process: | |
34 | ||
b13bfc3c AK |
35 | * A crafted packet that causes a kernel or userspace crash |
36 | (Availability). | |
f0664242 BP |
37 | |
38 | * A flow translation bug that misforwards traffic in a way likely | |
b13bfc3c | 39 | to hop over security boundaries (Integrity). |
f0664242 BP |
40 | |
41 | * An OpenFlow protocol bug that allows a controller to read | |
b13bfc3c | 42 | arbitrary files from the file system (Confidentiality). |
f0664242 BP |
43 | |
44 | * Misuse of the OpenSSL library that allows bypassing certificate | |
b13bfc3c | 45 | checks (Integrity). |
f0664242 BP |
46 | |
47 | * A bug (memory corruption, overflow, ...) that allows one to | |
48 | modify the behaviour of OVS through external configuration | |
b13bfc3c | 49 | interfaces such as OVSDB (Integrity). |
f0664242 | 50 | |
b13bfc3c AK |
51 | * Privileged information is exposed to unprivileged users |
52 | (Confidentiality). | |
f0664242 BP |
53 | |
54 | If in doubt, please do use the vulnerability management process. At | |
55 | worst, the response will be to report the bug through the usual | |
56 | channels. | |
57 | ||
58 | ||
59 | Step 1: Reception | |
60 | ----------------- | |
61 | ||
62 | To report an Open vSwitch vulnerability, send an email to the | |
63 | ovs-security mailing list (see "Contact" at the end of this document). | |
64 | A security team member should reply to the reporter acknowledging that | |
65 | the report has been received. | |
66 | ||
67 | Please consider reporting the information mentioned in | |
68 | REPORTING-BUGS.md, where relevant. | |
69 | ||
b13bfc3c AK |
70 | Reporters may ask for a GPG key while initiating contact with the |
71 | security team to deliver more sensitive reports. | |
72 | ||
f0664242 BP |
73 | The Linux kernel has its own vulnerability management process: |
74 | https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs | |
75 | Handling of vulnerabilities that affect both the Open vSwitch tree and | |
76 | the upstream Linux kernel should be reported through both processes. | |
77 | Please send your report as a single email to both the kernel and OVS | |
78 | security teams to allow those teams to most easily coordinate among | |
79 | themselves. | |
80 | ||
81 | ||
82 | Step 2: Assessment | |
83 | ------------------ | |
84 | ||
85 | The security team should discuss the vulnerability. The reporter | |
86 | should be included in the discussion (via "CC") to an appropriate | |
87 | degree. | |
88 | ||
89 | The assessment should determine which Open vSwitch versions are | |
90 | affected (e.g. every version, only the latest release, only unreleased | |
91 | versions), the privilege required to take advantage of the | |
92 | vulnerability (e.g. any network user, any local L2 network user, any | |
93 | local system user, connected OpenFlow controllers), the severity of | |
94 | the vulnerability, and how the vulnerability may be mitigated (e.g. by | |
95 | disabling a feature). | |
96 | ||
97 | The treatment of the vulnerability could end here if the team | |
98 | determines that it is not a realistic vulnerability. | |
99 | ||
100 | ||
101 | Step 3a: Document | |
102 | ---------------- | |
103 | ||
104 | The security team develops a security advisory document. The document | |
105 | credits the reporter and describes the vulnerability, including all of | |
106 | the relevant information from the assessment in step 2. The security | |
107 | team may, at its discretion, include the reporter (via "CC") in | |
108 | developing the security advisory document, but in any case should | |
109 | accept feedback from the reporter before finalizing the document. | |
110 | ||
111 | When the document is final, the security team should obtain a CVE for | |
112 | the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). | |
113 | ||
114 | ||
115 | Step 3b: Fix | |
116 | ------------ | |
117 | ||
118 | Steps 3a and 3b may proceed in parallel. | |
119 | ||
120 | The security team develops and obtains (private) reviews for patches | |
121 | that fix the vulnerability. If necessary, the security team pulls in | |
bb6c5fad | 122 | additional developers, who must agree to maintain confidentiality. |
f0664242 BP |
123 | |
124 | ||
125 | Step 4: Embargoed Disclosure | |
126 | ---------------------------- | |
127 | ||
128 | The security advisory and patches are sent to downstream stakeholders, | |
48beaa85 FL |
129 | with an embargo date and time set from the time sent. Downstream |
130 | stakeholders are expected not to deploy or disclose patches until | |
131 | the embargo is passed. | |
132 | ||
133 | A disclosure date is negotiated by the security team working with the | |
134 | bug submitter as well as vendors. However, the Open vSwitch security | |
135 | team holds the final say when setting a disclosure date. The timeframe | |
136 | for disclosure is from immediate (esp. if it's already publicly known) | |
137 | to a few weeks. As a basic default policy, we expect report date to | |
138 | disclosure date to be 3~5 business days. | |
f0664242 BP |
139 | |
140 | Operating system vendors are obvious downstream stakeholders. It may | |
141 | not be necessary to be too choosy about who to include: any major Open | |
142 | vSwitch user who is interested and can be considered trustworthy | |
143 | enough could be included. To become a downstream stakeholder, email | |
144 | the ovs-security mailing list. | |
145 | ||
b13bfc3c | 146 | If the vulnerability is already public, skip this step. |
f0664242 BP |
147 | |
148 | ||
b13bfc3c AK |
149 | Step 5: Public Disclosure |
150 | ------------------------- | |
f0664242 BP |
151 | |
152 | When the embargo expires, push the (reviewed) patches to appropriate | |
153 | branches, post the patches to the ovs-dev mailing list (noting that | |
154 | they have already been reviewed and applied), post the security | |
155 | advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and | |
156 | post the security advisory on the Open vSwitch webpage. | |
157 | ||
bc57376a FL |
158 | When the patch is applied to LTS (long-term support) branches, a new |
159 | version should be released. | |
160 | ||
f0664242 BP |
161 | The security advisory should be GPG-signed by a security team member |
162 | with a key that is in a public web of trust. | |
163 | ||
164 | ||
b13bfc3c | 165 | Contact |
f0664242 BP |
166 | ======= |
167 | ||
168 | Report security vulnerabilities to the ovs-security mailing list: | |
169 | security@openvswitch.org | |
170 | ||
171 | Report problems with this document to the ovs-bugs mailing list: | |
172 | bugs@openvswitch.org | |
173 | ||
174 | Visit http://openvswitch.org/ to learn more about Open vSwitch. |