Difference between revisions of "Samba Security Process"

From SambaWiki
(Publish our security process per team agreement. Not in wiki format because the original text file is easier to read.)
(add link to uploaded template security advisory)
Line 175: Line 175:
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
=Template security advisory=
The template security advisory is here: [[File:Template_security_advisory.txt]]

Revision as of 03:34, 17 May 2019

Reporting Security Defects in Samba

Please report all security defects to security@samba.org rather than on public mailing lists or in bugzilla.

Security Release Process

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:

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) using the initial
    advisory as evidence.
    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 (Name of issue)

See the attached initial advisory for what will be bug XXXX.

Please issue us a CVE. No release date is set yet, you will get the
normal mails when that is done.


(attach the advisory from step 3)

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.) Once each CVE patch and branch has passed, ask for review ASAP.

6f.) Get explicit review flags in Bugzilla (two explicit team review
     ticks, including yourself if need be, to indicate the patch is

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

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

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!

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
    - apply the security patchset
    - WHATSNEW.txt: add the release notes
    - add an empty announce.samba-$VERSION.quotation.txt file
    - GNUPGHOME=$PATH_TO_THE_RELEASE_KEY script/release.sh samba-stable create

    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:
     - push the advisory to the samba-web git repository:
     - 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 attachements and then
     un-select "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

[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