Samba Security Process: Difference between revisions
(add link to uploaded template security advisory) |
(Point to a video about our security process) |
||
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Below is the process the Samba Team follows to '''prepare a security release''' and co-ordinate the '''disclosure of a security vulnerability'''. |
|||
* Only [[Samba_Release_Planning|supported Samba versions]] are eligible for a security release. |
|||
* Security updates, once public, are listed on [https://www.samba.org/samba/history/security.html Samba Security Releases] |
|||
=Reporting Security Defects in Samba= |
=Reporting Security Defects in Samba= |
||
Please report all security defects to security@samba.org |
Please report all security issues or defects in Samba or concerning our infrustructure to '''security@samba.org''' and '''''never on''''' [https://www.samba.org/samba/irc.html IRC], [https://www.samba.org/samba/archives.html public mailing lists] or in [https://bugzilla.samba.org Bugzilla]! |
||
''For clarity, a Samba Team member will create the private Bugzilla issue mentioned below. |
|||
=Security Release Process= |
|||
'' |
|||
=A public security process for Samba= |
|||
The following process is followed by '''the [https://www.samba.org/samba/team Samba Team Member] working on the security issue'''. |
|||
We publish it as a service to the Free Software and broader software development community as a well-worked, practical process for ''responsible disclosure'' and to our aid our Samba community in knowing how we handle serious security issues in our code. |
|||
<pre> |
<pre> |
||
Security issues are usually reported via security@samba.org. |
Security issues are usually reported via security@samba.org. |
||
1.) Someone should feel responsible and make sure that it's really a |
1.) Someone should feel responsible and make sure that it's really a |
||
defect. If yes, we need one person who is responsible for |
security defect. If yes, we need one person who is responsible for |
||
issue beyond this point. This person coordinates the |
this specific issue beyond this point. This person coordinates the |
||
might delegate tasks, of course. |
further actions and might delegate tasks, of course. |
||
2.) Create a bug report with limited access to "Samba core developers" |
2.) Create a bug report with limited access to "Samba core developers" |
||
Change the summary so that it starts with |
only! Change the summary so that it starts with |
||
Add all information including reproducer |
"[EMBARGOED][SECURITY]". Add all information including reproducer |
||
etc. to the bug report. |
|||
3.) Write an initial advisory and attach it to the bug report. A |
3.) Write an initial advisory and attach it to the bug report. A |
||
available here: |
template is available here: |
||
team-info/doc/releases/template_security_advisory.txt |
team-info/doc/releases/template_security_advisory.txt |
||
3a.) Confirm with the initial reporter that they are willing to be |
|||
⚫ | |||
publicly thanked and any affiliation they wish to have noted. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
To: Red Hat Product Security <secalert@redhat.com> |
To: Red Hat Product Security <secalert@redhat.com> |
||
Subject: Another Samba CVE ( |
Subject: Another Samba CVE (bug XXXX) |
||
Red Hat Product Security, |
|||
Can I please get a CVE for what will be Samba Bug XXXX? |
|||
The Samba team has evaluated this issue and determined that it will |
|||
Please issue us a CVE. No release date is set yet, you will get the |
|||
require a security release. Details are confidential for now, but will |
|||
normal mails when that is done. |
|||
be clearly marked as bug XXXX (so you can connect the threads once |
|||
vendors are notified). |
|||
Thanks! |
Thanks! |
||
DO NOT attach the advisory from step 3. This avoids two issues: |
|||
- If Red Hat gets the advisory, they need to get GDPR permission for |
|||
the reporter name and we don't want to block on the back and forth |
|||
for that (see 3a). |
|||
- It keeps all vendors on the same basis. |
|||
5b.) If for any reason Red Hat is unable to assist with obtaining a |
|||
CVE number in time, the backup process is to fill in this form |
|||
https://cveform.mitre.org/ (explain the situation in the |
|||
submission) |
|||
6.) Write patches and tests and add them to the bug report. |
6.) Write patches and tests and add them to the bug report. |
||
Line 56: | Line 85: | ||
6b.) Ask for review of your WIP and final master patches ASAP |
6b.) Ask for review of your WIP and final master patches ASAP |
||
6c.) Prepare backports for all affected and supported versions |
6c.) Prepare backports for all affected and supported versions |
||
(1 file per version, even if identical). |
|||
Files should be named $CVE-$MAJOR-$VERSION.patch |
Files should be named $CVE-$MAJOR-$VERSION.patch |
||
⚫ | |||
E.g.: |
|||
⚫ | |||
6d.) Run *private* autobuild (see doc/autobuild.txt) or *private* |
6d.) Run *private* autobuild (see doc/autobuild.txt) or *private* |
||
Line 65: | Line 99: | ||
later in the process). |
later in the process). |
||
6e.) |
6e.) Mark the patch that has passed with the ci-passed flag in the |
||
bugzilla attachment details. |
|||
6f.) Once each CVE patch and branch has passed, ask for review ASAP. |
|||
6g.) Get explicit review flags in Bugzilla (two explicit team review |
|||
ticks, including yourself if need be, to indicate the patch is |
ticks, including yourself if need be, to indicate the patch is |
||
final). |
final). |
||
7.) Once all patches and the advisory are available and reviewed, ask |
7.) Once all patches and the advisory are available and reviewed, ask |
||
release manager for a release date. |
the release manager for a release date. |
||
7a.) Between now and the release, the release manager or their |
7a.) Between now and the release, the release manager or their |
||
Line 91: | Line 128: | ||
9a.) add samba-vendor to the CC list in the bug report, |
9a.) add samba-vendor to the CC list in the bug report, |
||
9b.) open the bug report by checking "Core developers, and Vendors |
9b.) open the bug report by checking "Core developers, and Vendors |
||
⚫ | |||
shipping Samba as part of their products" and removing "Samba |
|||
⚫ | |||
9c.) Add the planned release date to the bug or the tracking bug if |
9c.) Add the planned release date to the bug or the tracking bug if |
||
that has been created. This will be the first useful e-mail seen |
that has been created. This will be the first useful e-mail seen |
||
by our vendors. |
by our vendors. |
||
10.) 7 days before the release date, send an e-mail to |
10.) 7 days before the release date, send an e-mail to |
||
Line 162: | Line 201: | ||
remove the [EMBARGOED] tag from the bug report. |
remove the [EMBARGOED] tag from the bug report. |
||
14.) Mark as 'private' any sensitive comments or |
14.) Mark as 'private' any sensitive comments or attachments |
||
14a.) Then un-select the "Core developers, and Vendors shipping Samba |
|||
their products" restriction. |
as part of their products" restriction. |
||
15.) Address any minor improvements that were suggested after the |
15.) Address any minor improvements that were suggested after the |
||
Line 174: | Line 214: | ||
[1] https://access.redhat.com/security/team/contact/ |
[1] https://access.redhat.com/security/team/contact/ |
||
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator |
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator |
||
</pre> |
</pre> |
||
=Template security advisory= |
=Template security advisory= |
||
The template security advisory is here: [[File:Template_security_advisory.txt]] |
The template security advisory is here: [[File:Template_security_advisory.txt]] |
||
=In Video= |
|||
There is a [https://mirrors.dotsrc.org/fosdem/2019/K.1.105/security_flaws.mp4 Video of a presentation by Jeremy Allison] about this security process in practice. |
Revision as of 05:21, 14 June 2020
Below is the process the Samba Team follows to prepare a security release and co-ordinate the disclosure of a security vulnerability.
- Only supported Samba versions are eligible for a security release.
- Security updates, once public, are listed on Samba Security Releases
Reporting Security Defects in Samba
Please report all security issues or defects in Samba or concerning our infrustructure to security@samba.org and never on IRC, public mailing lists or in Bugzilla!
For clarity, a Samba Team member will create the private Bugzilla issue mentioned below.
A public security process for Samba
The following process is followed by the Samba Team Member working on the security issue.
We publish it as a service to the Free Software and broader software development community as a well-worked, practical process for responsible disclosure and to our aid our Samba community in knowing how we handle serious security issues in our code.
Security issues are usually reported via security@samba.org. 1.) Someone should feel responsible and make sure that it's really a security defect. If yes, we need one person who is responsible for this specific issue beyond this point. This person coordinates the further actions and might delegate tasks, of course. 2.) Create a bug report with limited access to "Samba core developers" only! Change the summary so that it starts with "[EMBARGOED][SECURITY]". Add all information including reproducer etc. to the bug report. 3.) Write an initial advisory and attach it to the bug report. A template is available here: team-info/doc/releases/template_security_advisory.txt 3a.) Confirm with the initial reporter that they are willing to be publicly thanked and any affiliation they wish to have noted. 4.) Do a CVSSv3 calculation ([2]) and add it to the bug report and the advisory. 5.) Ask for a CVE (usually Red Hat Product Security <secalert@redhat.com> (see [1] for GPG key etc.) does help out on this one). After receiving the CVE number, please add it as an alias to the bug report advisory and to the summary. To: Red Hat Product Security <secalert@redhat.com> Subject: Another Samba CVE (bug XXXX) Red Hat Product Security, Can I please get a CVE for what will be Samba Bug XXXX? The Samba team has evaluated this issue and determined that it will require a security release. Details are confidential for now, but will be clearly marked as bug XXXX (so you can connect the threads once vendors are notified). Thanks! DO NOT attach the advisory from step 3. This avoids two issues: - If Red Hat gets the advisory, they need to get GDPR permission for the reporter name and we don't want to block on the back and forth for that (see 3a). - It keeps all vendors on the same basis. 5b.) If for any reason Red Hat is unable to assist with obtaining a CVE number in time, the backup process is to fill in this form https://cveform.mitre.org/ (explain the situation in the submission) 6.) Write patches and tests and add them to the bug report. 6a.) ALL commits in the patch should have a CVE prefix and a BUG tag eg: CVE-2038-12345 dsdb: time wrap at end of unix time At time_t rollover all AD security is lost due to integer wrap on 32-bit systems BUG: https://bugzilla.samba.org/show_bug.cgi?id=999999 Signed-off-by: Time Lord <time@samba.org> 6b.) Ask for review of your WIP and final master patches ASAP 6c.) Prepare backports for all affected and supported versions (1 file per version, even if identical). Files should be named $CVE-$MAJOR-$VERSION.patch E.g.: CVE-2018-14629-4.9-01.patch 6d.) Run *private* autobuild (see doc/autobuild.txt) or *private* Gitlab CI for each CVE and each maintained branch. (This allows the release manager to defer some patches if problems appear later in the process). 6e.) Mark the patch that has passed with the ci-passed flag in the bugzilla attachment details. 6f.) Once each CVE patch and branch has passed, ask for review ASAP. 6g.) Get explicit review flags in Bugzilla (two explicit team review ticks, including yourself if need be, to indicate the patch is final). 7.) Once all patches and the advisory are available and reviewed, ask the release manager for a release date. 7a.) Between now and the release, the release manager or their delegate will run a *private* autobuild of the exact combination of patches the be released. 7b.) If multiple issues are being released in a batch, create a tracking bug that is blocked by the CVEs to be addressed in this bundle. 8.) Finish the advisory and attach it to the bug report as advisory-$CVE.txt. Ask for review. (This must be after getting the release date so the correct version numbers can be included). 9.) ~10 days before the release date, confirm every patch and the CVE text still has the correct reviews (due to additional feedback for example). 9a.) add samba-vendor to the CC list in the bug report, 9b.) open the bug report by checking "Core developers, and Vendors shipping Samba as part of their products" and removing "Samba Core Developers". 9c.) Add the planned release date to the bug or the tracking bug if that has been created. This will be the first useful e-mail seen by our vendors. 10.) 7 days before the release date, send an e-mail to samba@lists.samba.org, samba-technical@lists.samba.org and samba-announce@lists.samba.org indicating there will be a security release and the broad component it impacts. This is to allow large installations time to prepare for security patching. For example: To: samba-announce@lists.samba.org Cc: Upstream Samba Technical Mailing list <samba-technical@lists.samba.org>, samba@lists.samba.org Subject: Heads-up: Security Releases ahead! Hi, this is a heads-up that there will be Samba security updates on Tuesday, XXXXX YYth. Please make sure that your Samba servers will be updated soon after the release! Impacted components: - AD DC (CVSS 7.5, High) - client (CVSS 5.9, Medium) - file server / classic DC (CVSS 6.8 Medium) 10a.) Note that this represents the final GO/NO-GO point. In order to facilitate creation of tarballs etc, after this date the patches and CVE text *must not change* or else the release will need to be publicly rescheduled, patches dropped or other appropriate action taken at the absolute discretion of the release manager. 11.) The release manager or their delegate will prepare the tarballs in the *stable* branches: - git fetch - git rebase - git merge -ff-only the VERSION bump commit from the corresponding test branch - apply the security patchset - WHATSNEW.txt: add the release notes - VERSION: disable GIT_SNAPSHOT - add an empty announce.samba-$VERSION.quotation.txt file - GNUPGHOME=$PATH_TO_THE_RELEASE_KEY script/release.sh samba-stable create DO NOT PUBLISH ANYTHING BEFORE THE END OF EMBARGO! On the release day: Upload the files and publish the announcements as described in steps 3.) and 4.) in team-info/doc/releases/howto_releases.txt 12.) Additional steps for the release manager: - upload the signed security patch(es) to the ftp server: samba-bugs@samba.org:/home/ftp/pub/samba/patches/security/ - push the advisory to the samba-web git repository: samba-web/security/ - update samba-web/history/security.html Merge the tags to the test branches: - git fetch - git rebase - git merge $TAG - VERSION: bump version - push without autobuild: LC_SAMBA_AUTOBUILD_PUSH=1 git push-v4-X-test-skip-autobuild 13.) After shipping the releases, the responsible person must make sure that the patches find their way into the master branch and remove the [EMBARGOED] tag from the bug report. 14.) Mark as 'private' any sensitive comments or attachments 14a.) Then un-select the "Core developers, and Vendors shipping Samba as part of their products" restriction. 15.) Address any minor improvements that were suggested after the patches were frozen and incorporate those into commits in master. 16.) Close out bug report when patches have been pushed to *all* relevant branches. [1] https://access.redhat.com/security/team/contact/ [2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Template security advisory
The template security advisory is here: File:Template security advisory.txt
In Video
There is a Video of a presentation by Jeremy Allison about this security process in practice.