Security private reporting: Difference between revisions
m (Fix formatting) |
(Add embargoes case) |
||
| (17 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
= (WIP) Security team and private reporting = | = (WIP) Security team and private reporting = | ||
Note: this page is undergoing migration to [https://docs.yoctoproject.org/ the official Yocto Project documentation]. | |||
== How to Report a Potential Vulnerability? == | |||
If you would like to report a public issue (for example, one with a released CVE number), please report it using the [https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security Bugzilla]. | |||
If you are dealing with a not-yet-released or urgent issue, please send a message to security AT yoctoproject DOT org, including as many details as possible: the layer or software module affected, the recipe and its version, and any example code, if available. | |||
''' Branches maintained with security fixes''' | ''' Branches maintained with security fixes''' | ||
---------------------------------------------- | ---------------------------------------------- | ||
See [https://wiki.yoctoproject.org/wiki/ | See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS]for detailed info regarding the policies and maintenance of Stable branch. | ||
Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them. | The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all releases of the Yocto Project. Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them for significant issues. | ||
== How to Contact the Yocto Project regarding Security == | == How to Contact the Yocto Project regarding Security == | ||
| Line 26: | Line 30: | ||
'''What you should do if you find a security vulnerability''' | '''What you should do if you find a security vulnerability''' | ||
--------------------------------------------- | --------------------------------------------- | ||
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source | If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source software built or used by the Yocto Project, please report this to the Yocto Project Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at the Yocto Project as well. | ||
If you believe this is highly sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated. | If you believe this is highly sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated. | ||
| Line 32: | Line 36: | ||
'''What Yocto Security Team does when it receives a security vulnerability''' | '''What Yocto Security Team does when it receives a security vulnerability''' | ||
--------------------------------------------- | --------------------------------------------- | ||
The YP Security Team team performs a quick analysis and | The YP Security Team team performs a quick analysis and would usually report the flaw to the upstream project. Normally the upstream project analyzes the problem. If they deem it a real security problem in their software, they develop and release a fix following their own security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it. | ||
The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are normally non-public. | The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are normally non-public. | ||
| Line 44: | Line 48: | ||
If an upstream project does not fix the problem in a reasonable time, the Yocto's Security Team will contact other interested parties (usually other distributions) in the community and together try to solve the vulnerability as quickly as possible. | If an upstream project does not fix the problem in a reasonable time, the Yocto's Security Team will contact other interested parties (usually other distributions) in the community and together try to solve the vulnerability as quickly as possible. | ||
The Yocto Project Security team adheres to the 90 days disclosure policy by default. | The Yocto Project Security team adheres to the 90 days disclosure policy by default. An increase of the embargo time is possible when necessary. | ||
== Security Team Appointment == | == Security Team Appointment == | ||
The Yocto Project Security Team consists of at least three members. When new members are needed, the YP TSC asks for nominations by public channels including a nomination deadline. Self-nominations are possible. When the limit time is reached, the YP TSC posts the list of candidates for the comments of project participants and developers. Comments may be sent publicly or privately to the YP and OE TSCs. The candidates are approved by both YP TSC and OE TSC and the final list of the team members is announced publicly. The aim is to have people representing technical leadership, security knowledge and infrastructure present with enough people to provide backup/coverage but keep the notification list small enough to minimise information risk and maintain trust. | |||
YP Security Team members may resign at any time. | |||
== Security Team Operations == | |||
The work of the Security Team might require high confidentiality. Team members are individuals selected by merit and do not represent the companies they work for. They do not share information about confidential issues outside of the team and do not hint about ongoing embargoes. | |||
Team members can bring in domain experts as needed. Those people should be added to individual issues only and adhere to the same standards as the YP Security Team. | |||
The YP security team organizes its meetings and communication as needed. | |||
When the YP Security team receives a report about a potential security vulnerability, they quickly analyze and notify the reporter of the result. They might also request more information. | |||
If the issue is confirmed and affects the code maintained by the YP, they confidentially notify maintainers of that code and work with them to prepare a fix. | |||
If the issue is confirmed and affects an upstream project, the YP security team notifies the project. Usually, the upstream project analyzes the problem again. If they deem it a real security problem in their software, they develop and release a fix following their security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it. | |||
The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are generally non-public. The YP Security Team participates in the discussion as needed. They might also include the YP maintainer of the affected package. | |||
When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published. | |||
When the fix is publicly available, the YP security team member or the package maintainer sends patches against the YP code base, following usual procedures, including public code review. | |||
== Handling multi-project embargoes == | |||
In rare cases, a severe security issue affects multiple projects. This might be numerous projects having a similar issue because of design, coding pattern, or reuse of the same code (an example of this situation is CVE-2023-44487 where multiple web servers share a design weakness). It might also be a high-profile issue in a commonly used library (like OpenSSL). In such cases, the project, learning first about the issue, might decide to notify other affected projects confidentially so that they come up with a synchronized fix. It might also be the affected project informing major distributions to roll out the update simultaneously. | |||
Such notifications happen over confidential, non-public means. Typically, the project initiating this "embargo" directly notifies a selected number of people from each project, including a subset of the security team. When Yocto Project is a part of such a notified group, developers prepare fixes on separate infrastructure and test it. They might also include additional developers and domain experts who can help with the fix and eventual regressions. When the embargo is lifted, they send a patch to the relevant public list, and the usual review process starts. | |||
== Current Security Team Members == | == Current Security Team Members == | ||
For secure communications, please send your messages encrypted using the GPG keys. Remember message headers are not encrypted so do not include sensitive information in the subject line. | |||
* Richard Purdie '''<richard.purdie@linuxfoundation.org>''' | |||
: [https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org Public key] | |||
* Michael Halstead '''<mhalstead [at] linuxfoundation [dot] org>''' | |||
: Public keys: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969 Michael Halstead] or [https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969 Michael Halstead] | |||
* Ross Burton '''<ross@burtonini.com>''' | |||
: [https://keys.openpgp.org/search?q=ross%40burtonini.com Public key] | |||
: | * Marta Rybczynska '''<marta DOT rybczynska [at] syslinbit [dot] com>''' | ||
: [https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com Public key] | |||
* Steve Sakoman '''<steve [at] sakoman [dot] com>''' | |||
: [https://keys.openpgp.org/search?q=steve%40sakoman.com Public key] | |||
Latest revision as of 07:06, 30 October 2023
(WIP) Security team and private reporting
Note: this page is undergoing migration to the official Yocto Project documentation.
How to Report a Potential Vulnerability?
If you would like to report a public issue (for example, one with a released CVE number), please report it using the Security Bugzilla.
If you are dealing with a not-yet-released or urgent issue, please send a message to security AT yoctoproject DOT org, including as many details as possible: the layer or software module affected, the recipe and its version, and any example code, if available.
Branches maintained with security fixes
See Stable release and LTSfor detailed info regarding the policies and maintenance of Stable branch.
The Release page contains a list of all releases of the Yocto Project. Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them for significant issues.
How to Contact the Yocto Project regarding Security
We have set up two security-related mailing lists:
- Public List
- yocto [dash] security [at] yoctoproject[dot] org
- This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches and security-related initiatives. For more information, including subscription information, please see the yocto-security mailing list info page.
- Private List
- security [at] yoctoproject [dot] org
- This is a private mailing list for reporting non-published potential vulnerabilities. The list is monitored by the Yocto Project Security team.
What you should do if you find a security vulnerability
If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source software built or used by the Yocto Project, please report this to the Yocto Project Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at the Yocto Project as well. If you believe this is highly sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.
What Yocto Security Team does when it receives a security vulnerability
The YP Security Team team performs a quick analysis and would usually report the flaw to the upstream project. Normally the upstream project analyzes the problem. If they deem it a real security problem in their software, they develop and release a fix following their own security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it.
The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are normally non-public.
When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published.
If an upstream project does not respond quickly
If an upstream project does not fix the problem in a reasonable time, the Yocto's Security Team will contact other interested parties (usually other distributions) in the community and together try to solve the vulnerability as quickly as possible.
The Yocto Project Security team adheres to the 90 days disclosure policy by default. An increase of the embargo time is possible when necessary.
Security Team Appointment
The Yocto Project Security Team consists of at least three members. When new members are needed, the YP TSC asks for nominations by public channels including a nomination deadline. Self-nominations are possible. When the limit time is reached, the YP TSC posts the list of candidates for the comments of project participants and developers. Comments may be sent publicly or privately to the YP and OE TSCs. The candidates are approved by both YP TSC and OE TSC and the final list of the team members is announced publicly. The aim is to have people representing technical leadership, security knowledge and infrastructure present with enough people to provide backup/coverage but keep the notification list small enough to minimise information risk and maintain trust.
YP Security Team members may resign at any time.
Security Team Operations
The work of the Security Team might require high confidentiality. Team members are individuals selected by merit and do not represent the companies they work for. They do not share information about confidential issues outside of the team and do not hint about ongoing embargoes.
Team members can bring in domain experts as needed. Those people should be added to individual issues only and adhere to the same standards as the YP Security Team.
The YP security team organizes its meetings and communication as needed.
When the YP Security team receives a report about a potential security vulnerability, they quickly analyze and notify the reporter of the result. They might also request more information.
If the issue is confirmed and affects the code maintained by the YP, they confidentially notify maintainers of that code and work with them to prepare a fix.
If the issue is confirmed and affects an upstream project, the YP security team notifies the project. Usually, the upstream project analyzes the problem again. If they deem it a real security problem in their software, they develop and release a fix following their security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it.
The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are generally non-public. The YP Security Team participates in the discussion as needed. They might also include the YP maintainer of the affected package.
When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published.
When the fix is publicly available, the YP security team member or the package maintainer sends patches against the YP code base, following usual procedures, including public code review.
Handling multi-project embargoes
In rare cases, a severe security issue affects multiple projects. This might be numerous projects having a similar issue because of design, coding pattern, or reuse of the same code (an example of this situation is CVE-2023-44487 where multiple web servers share a design weakness). It might also be a high-profile issue in a commonly used library (like OpenSSL). In such cases, the project, learning first about the issue, might decide to notify other affected projects confidentially so that they come up with a synchronized fix. It might also be the affected project informing major distributions to roll out the update simultaneously.
Such notifications happen over confidential, non-public means. Typically, the project initiating this "embargo" directly notifies a selected number of people from each project, including a subset of the security team. When Yocto Project is a part of such a notified group, developers prepare fixes on separate infrastructure and test it. They might also include additional developers and domain experts who can help with the fix and eventual regressions. When the embargo is lifted, they send a patch to the relevant public list, and the usual review process starts.
Current Security Team Members
For secure communications, please send your messages encrypted using the GPG keys. Remember message headers are not encrypted so do not include sensitive information in the subject line.
- Richard Purdie <richard.purdie@linuxfoundation.org>
- Michael Halstead <mhalstead [at] linuxfoundation [dot] org>
- Public keys: Michael Halstead or Michael Halstead
- Ross Burton <ross@burtonini.com>
- Marta Rybczynska <marta DOT rybczynska [at] syslinbit [dot] com>
- Steve Sakoman <steve [at] sakoman [dot] com>
