diff options
author | Marta Rybczynska <rybczynska@gmail.com> | 2023-10-25 15:12:02 +0200 |
---|---|---|
committer | Steve Sakoman <steve@sakoman.com> | 2023-11-09 04:44:46 -1000 |
commit | 05b8a1b5c1f06fd047f428948535c2da63d0c4a6 (patch) | |
tree | 2870668eb137bac0e50ec69d1db1fcccae5b970d | |
parent | f2f7ea77d5786122d40961ce4c134b7b58dc5562 (diff) | |
download | poky-05b8a1b5c1f06fd047f428948535c2da63d0c4a6.tar.gz |
dev-manual: add security team processes
Add the initial version of the section on vulnerability reports,
operations of the Security Team with a
transcription of https://wiki.yoctoproject.org/wiki/Security_private_reporting
(From yocto-docs rev: 763d66c72bf60dc06195acc6168a9535fdf7b302)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
-rw-r--r-- | documentation/dev-manual/index.rst | 1 | ||||
-rw-r--r-- | documentation/dev-manual/security-subjects.rst | 189 |
2 files changed, 190 insertions, 0 deletions
diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst index 3618e51c8d..e731a70476 100644 --- a/documentation/dev-manual/index.rst +++ b/documentation/dev-manual/index.rst | |||
@@ -44,6 +44,7 @@ Yocto Project Development Tasks Manual | |||
44 | runtime-testing | 44 | runtime-testing |
45 | debugging | 45 | debugging |
46 | licenses | 46 | licenses |
47 | security-subjects | ||
47 | vulnerabilities | 48 | vulnerabilities |
48 | sbom | 49 | sbom |
49 | error-reporting-tool | 50 | error-reporting-tool |
diff --git a/documentation/dev-manual/security-subjects.rst b/documentation/dev-manual/security-subjects.rst new file mode 100644 index 0000000000..1b02b6a9e9 --- /dev/null +++ b/documentation/dev-manual/security-subjects.rst | |||
@@ -0,0 +1,189 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | Dealing with Vulnerability Reports | ||
4 | ********************************** | ||
5 | |||
6 | The Yocto Project and OpenEmbedded are open-source, community-based projects | ||
7 | used in numerous products. They assemble multiple other open-source projects, | ||
8 | and need to handle security issues and practices both internal (in the code | ||
9 | maintained by both projects), and external (maintained by other projects and | ||
10 | organizations). | ||
11 | |||
12 | This manual assembles security-related information concerning the whole | ||
13 | ecosystem. It includes information on reporting a potential security issue, | ||
14 | the operation of the YP Security team and how to contribute in the | ||
15 | related code. It is written to be useful for both security researchers and | ||
16 | YP developers. | ||
17 | |||
18 | How to report a potential security vulnerability? | ||
19 | ================================================= | ||
20 | |||
21 | If you would like to report a public issue (for example, one with a released | ||
22 | CVE number), please report it using the | ||
23 | :yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`. | ||
24 | |||
25 | If you are dealing with a not-yet-released issue, or an urgent one, please send | ||
26 | a message to security AT yoctoproject DOT org, including as many details as | ||
27 | possible: the layer or software module affected, the recipe and its version, | ||
28 | and any example code, if available. This mailing list is monitored by the | ||
29 | Yocto Project Security team. | ||
30 | |||
31 | For each layer, you might also look for specific instructions (if any) for | ||
32 | reporting potential security issues in the specific ``SECURITY.md`` file at the | ||
33 | root of the repository. Instructions on how and where submit a patch are | ||
34 | usually available in ``README.md``. If this is your first patch to the | ||
35 | Yocto Project/OpenEmbedded, you might want to have a look into the | ||
36 | Contributor's Manual section | ||
37 | ":ref:`contributor-guide/submit-changes:preparing changes for submission`". | ||
38 | |||
39 | Branches maintained with security fixes | ||
40 | --------------------------------------- | ||
41 | |||
42 | See the | ||
43 | :ref:`Release process <ref-manual/release-process:Stable Release Process>` | ||
44 | documentation for details regarding the policies and maintenance of stable | ||
45 | branches. | ||
46 | |||
47 | The :yocto_wiki:`Releases page </Releases>` contains a list | ||
48 | of all releases of the Yocto Project. Versions in gray are no longer actively | ||
49 | maintained with security patches, but well-tested patches may still be accepted | ||
50 | for them for significant issues. | ||
51 | |||
52 | Security-related discussions at the Yocto Project | ||
53 | ------------------------------------------------- | ||
54 | |||
55 | We have set up two security-related mailing lists: | ||
56 | |||
57 | - Public List: yocto [dash] security [at] yoctoproject[dot] org | ||
58 | |||
59 | This is a public mailing list for anyone to subscribe to. This list is an | ||
60 | open list to discuss public security issues/patches and security-related | ||
61 | initiatives. For more information, including subscription information, | ||
62 | please see the :yocto_lists:`yocto-security mailing list info page </g/yocto-security>`. | ||
63 | |||
64 | - Private List: security [at] yoctoproject [dot] org | ||
65 | |||
66 | This is a private mailing list for reporting non-published potential | ||
67 | vulnerabilities. The list is monitored by the Yocto Project Security team. | ||
68 | |||
69 | |||
70 | What you should do if you find a security vulnerability | ||
71 | ------------------------------------------------------- | ||
72 | |||
73 | If you find a security flaw: a crash, an information leakage, or anything that | ||
74 | can have a security impact if exploited in any Open Source software built or | ||
75 | used by the Yocto Project, please report this to the Yocto Project Security | ||
76 | Team. If you prefer to contact the upstream project directly, please send a | ||
77 | copy to the security team at the Yocto Project as well. If you believe this is | ||
78 | highly sensitive information, please report the vulnerability in a secure way, | ||
79 | i.e. encrypt the email and send it to the private list. This ensures that | ||
80 | the exploit is not leaked and exploited before a response/fix has been generated. | ||
81 | |||
82 | Security team | ||
83 | ============= | ||
84 | |||
85 | The Yocto Project/OpenEmbedded security team coordinates the work on security | ||
86 | subjects in the project. All general discussion takes place publicly. The | ||
87 | Security Team only uses confidential communication tools to deal with private | ||
88 | vulnerability reports before they are released. | ||
89 | |||
90 | Security team appointment | ||
91 | ------------------------- | ||
92 | |||
93 | The Yocto Project Security Team consists of at least three members. When new | ||
94 | members are needed, the Yocto Project Technical Steering Committee (YP TSC) | ||
95 | asks for nominations by public channels including a nomination deadline. | ||
96 | Self-nominations are possible. When the limit time is | ||
97 | reached, the YP TSC posts the list of candidates for the comments of project | ||
98 | participants and developers. Comments may be sent publicly or privately to the | ||
99 | YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded | ||
100 | Technical Steering Committee (OE TSC) and the final list of the team members | ||
101 | is announced publicly. The aim is to have people representing technical | ||
102 | leadership, security knowledge and infrastructure present with enough people | ||
103 | to provide backup/coverage but keep the notification list small enough to | ||
104 | minimize information risk and maintain trust. | ||
105 | |||
106 | YP Security Team members may resign at any time. | ||
107 | |||
108 | Security Team Operations | ||
109 | ------------------------ | ||
110 | |||
111 | The work of the Security Team might require high confidentiality. Team members | ||
112 | are individuals selected by merit and do not represent the companies they work | ||
113 | for. They do not share information about confidential issues outside of the team | ||
114 | and do not hint about ongoing embargoes. | ||
115 | |||
116 | Team members can bring in domain experts as needed. Those people should be | ||
117 | added to individual issues only and adhere to the same standards as the YP | ||
118 | Security Team. | ||
119 | |||
120 | The YP security team organizes its meetings and communication as needed. | ||
121 | |||
122 | When the YP Security team receives a report about a potential security | ||
123 | vulnerability, they quickly analyze and notify the reporter of the result. | ||
124 | They might also request more information. | ||
125 | |||
126 | If the issue is confirmed and affects the code maintained by the YP, they | ||
127 | confidentially notify maintainers of that code and work with them to prepare | ||
128 | a fix. | ||
129 | |||
130 | If the issue is confirmed and affects an upstream project, the YP security team | ||
131 | notifies the project. Usually, the upstream project analyzes the problem again. | ||
132 | If they deem it a real security problem in their software, they develop and | ||
133 | release a fix following their security policy. They may want to include the | ||
134 | original reporter in the loop. There is also sometimes some coordination for | ||
135 | handling patches, backporting patches etc, or just understanding the problem | ||
136 | or what caused it. | ||
137 | |||
138 | When the fix is publicly available, the YP security team member or the | ||
139 | package maintainer sends patches against the YP code base, following usual | ||
140 | procedures, including public code review. | ||
141 | |||
142 | What Yocto Security Team does when it receives a security vulnerability | ||
143 | ----------------------------------------------------------------------- | ||
144 | |||
145 | The YP Security Team team performs a quick analysis and would usually report | ||
146 | the flaw to the upstream project. Normally the upstream project analyzes the | ||
147 | problem. If they deem it a real security problem in their software, they | ||
148 | develop and release a fix following their own security policy. They may want | ||
149 | to include the original reporter in the loop. There is also sometimes some | ||
150 | coordination for handling patches, backporting patches etc, or just | ||
151 | understanding the problem or what caused it. | ||
152 | |||
153 | The security policy of the upstream project might include a notification to | ||
154 | Linux distributions or other important downstream projects in advance to | ||
155 | discuss coordinated disclosure. These mailing lists are normally non-public. | ||
156 | |||
157 | When the upstream project releases a version with the fix, they are responsible | ||
158 | for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and | ||
159 | the CVE record published. | ||
160 | |||
161 | If an upstream project does not respond quickly | ||
162 | ----------------------------------------------- | ||
163 | |||
164 | If an upstream project does not fix the problem in a reasonable time, | ||
165 | the Yocto's Security Team will contact other interested parties (usually | ||
166 | other distributions) in the community and together try to solve the | ||
167 | vulnerability as quickly as possible. | ||
168 | |||
169 | The Yocto Project Security team adheres to the 90 days disclosure policy | ||
170 | by default. An increase of the embargo time is possible when necessary. | ||
171 | |||
172 | Current Security Team members | ||
173 | ----------------------------- | ||
174 | |||
175 | For secure communications, please send your messages encrypted using the GPG | ||
176 | keys. Remember, message headers are not encrypted so do not include sensitive | ||
177 | information in the subject line. | ||
178 | |||
179 | - Ross Burton: <ross@burtonini.com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__ | ||
180 | |||
181 | - Michael Halstead: <mhalstead [at] linuxfoundation [dot] org> | ||
182 | `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__ | ||
183 | or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__ | ||
184 | |||
185 | - Richard Purdie: <richard.purdie@linuxfoundation.org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__ | ||
186 | |||
187 | - Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__ | ||
188 | |||
189 | - Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__ | ||