Security Tracking Bugs

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (Sparks moved page Security/TrackingBugs to Security Tracking Bugs: Un-nestng)
(make this reflect 2014 reality)
Line 1: Line 1:
= Using Tracking Bugs =
+
= How to Use Security Tracking Bugs =
 +
 
 +
This document aims to outline the proper way to use, and the expectations surrounding the use of, security tracking bugs for Fedora and EPEL.
  
 
== Handling tracking bugs in Bugzilla ==
 
== Handling tracking bugs in Bugzilla ==
Line 5: Line 7:
 
=== Parent Bug ===
 
=== Parent Bug ===
  
Let's imagine a situation where a security flaw was found in ''yoyodine'' package. A member of Fedora Security Response team enters it in bugzilla under Security Response Team. Then he requests a [http://cve.mitre.org/ CVE] identifier for the issue.  As he found the mention of the bug while reading a public mailing list, he creates a public bug. When he gets the CVE for the bug, he adds it to the begining of the Summary line and sets an appropriate alias=CVE number.
+
The workflow for resolving security issues in Fedora and EPEL is through the use of bugs in bugzilla. This consists of both a parent bug (usually with one or more [http://cve.mitre.org/ CVE] names referenced), and tracking bugs that are used to track the fix of the flaws in the affected products.
  
* Parent bug is entered in the ''Security Response'' product
+
Red Hat Product Security largely manages the entry of flaw (parent) bugs and will file tracking bugs as appropriate.  What follows is an overview of that process.
* Parent bug's subject begins with the ''CVE''
+
* Parent bug is ''publicly viewable''
+
* Parent bug has an alias=''CVE''
+
* Parent bug is assigned to the ''Fedora Security Response'' team
+
* Parent bug has a Security keyword set
+
  
=== Tracking Bugs ===
+
Suppose a flaw is found in the "yoyodine" package.  A member of Red Hat Product Security creates a bug in bugzilla, in the Security Response product, with a component of "vulnerability".  If a CVE is already known, it is noted in the bug (by setting the alias and prepending it to the Summary field).  If it is not known, a CVE is requested on the [http://oss-security.openwall.org/wiki/mailing-lists/oss-security oss-security mailing list].
  
As the bug obviously affects ''yoyodine'' package, he triages it and finds that it affects all supported Fedora releases, and also EPEL. He creates appropriate tracking bugs (with a script). Later it is found out that the vulnerable code is reused in ''foobar'' package that is present in EPEL5 (common situation with ''xpdf'' code). He adds appropriate tracking bug.
+
Some of the parent (CVE) bug's attributes include:
  
* Tracking bug belongs to ''Fedora Project Contributors'' group
+
* It is in the "Security Response" product
* Tracking bug is depended on by the ''Parent bug''
+
* Applicable CVEs are added as bug aliases
* Tracking bug is entered into respective Product/Component/Version where the flaw needs to be addresed
+
* Applicable CVEs are prefixed to the Summary description
* Tracking bug is assigned to the developer
+
* Public issues result in public bugs (no group restrictions)
* The description of the tracking bug doesn't contain information about the flaw, but rather refers to the Parent bug and describes how to handle the flaw
+
* It is always assigned to the "Red Hat Security Response Team" user
* Tracking bug has a Security keyword set
+
* The priority/severity map to the [https://access.redhat.com/security/updates/classification Red Hat impact rating]
 +
* The "Security" keyword is set
  
The situation then looks like this:
 
<pre>
 
(public, alias=CVE-2007-9999)
 
|- #222222: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [FC7]
 
|  (group Fedora Project Contributors, component=yoyodine)
 
|- #333333: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [F8]
 
|  (group Fedora Project Contributors, component=yoyodine)
 
|- #444444: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [EPEL5]
 
|  (group Fedora Project Contributors, component=foobar)
 
</pre>
 
  
== Handling tracking bugs in Bodhi ==
+
=== Tracking Bugs ===
  
=== The procedure ===
+
During the process of investigation, if it is found that Fedora and/or EPEL are affected by this flaw, Red Hat Product Security will create the tracking bug(s) via the use of a script.  If it is later found that the same code exists in another package (although we try not to embed one package in another, it does happen, particularly with libraries), new tracking bugs will be created against that package for the affected products ("xpdf" historically has suffered from this problem).
  
The maintainer commits the fixes, builds packages and creates an update request. He refers to both parent bug and tracking bug. Bodhi is able to identify that the bug is a tracking bug and doesn't include it in the new package announce mail. Bodhi closes the tracking bug, and in case all other bugs that Parent depends on it also closes the Parent. To keep track, Bodhi adds comments to both Parent and Tracking bug.
+
Some of the tracking bug characteristics include:
 +
 
 +
* It depends on the parent bug
 +
* It is filed against the appropriate Product/Component/Version for the affected package/product
 +
* It is assigned to the owner of the component
 +
* Applicable CVEs are prefixed to the Summary description
 +
* Applicable affected versions are appended to the Summary description (such as "[fedora-all]" or "[epel-6]")
 +
* The "Security" and "SecurityTracking" keywords are set
 +
* The initial description and comment(s) of the bug don't describe the flaw(s) but refer the assignee to the parent bug for details/patches/etc, but do indicate how to correct the flaw via established process (either a filled-out template to use with "fedpkg update" or a link to use with Bodhi).
 +
 
 +
== Handling tracking bugs in Bodhi ==
  
=== Proposed changes to Bodhi ===
+
The maintainer commits the fixes, builds packages and creates an update request. He refers to both parent bug and tracking bug. Bodhi is able to identify that the bug is a tracking bug and doesn't include it in the new package announce mail. Bodhi closes the tracking bug, and in case all other bugs that Parent depends on it also closes the parent. To keep track, Bodhi adds comments to both the parent and the tracking bug.
'''These proposed changes have been implemented. -lmacken'''
+
  
This might include things that are already implemented in Bodhi that I am not aware of.
+
Note: The comments in the tracking bug provide a link to Bodhi to ease the inclusion of bugs, particularly when there are a large number of parent bugs.
* Bodhi shouldn't include the bug belonging to ''Fedora Project Contributors'' in the mail (Note: Wouldn't it be better to identify a tracking bug with a dedicated keyword rather than group membership?)
+
* Bodhi should close the bug only in case all bugs it depends on are closed and it is not in NEW state
+
* There is no need to refer to CVE from Bodhi, security bugzillas allways refer to CVE themselves
+
* Bodhi should include the Summary of the bugzillas rather than just the number, so that reference to CVE is visible in the mail
+
* Bodhi should add comments to the bugs when the update is created, and pushed to testing, not just when it gets live. (This would save the SRT from unnecessary pings to developers and keep users updated)
+
  
This would change the ''References'' section in update announce mails from:
+
== Handling tracking bugs via fedpkg ==
<pre>
+
References:
+
  
[ 1 ]  Bug #284511
+
The maintainer commits the fixes and builds packages and then submits the update to Bodhi via [[Package_update_HOWTO#Submit_your_update_to_Bodhi]].
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511
+
[ 2 ] CVE-2007-4727
+
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4727
+
</pre>
+
to:
+
<pre>
+
References:
+
  
[ 1 ]  CVE-2007-4727 FastCGI header overrun in lighttpd's mod_fastcgi
+
Note: The comments in the tracking bug (only since July 2014) provide a template that can be used (cut-n-paste) for the "fedpkg update" process.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511
+
</pre>
+
  
  
 
[[Category:Security]]
 
[[Category:Security]]

Revision as of 16:49, 18 July 2014

Contents

How to Use Security Tracking Bugs

This document aims to outline the proper way to use, and the expectations surrounding the use of, security tracking bugs for Fedora and EPEL.

Handling tracking bugs in Bugzilla

Parent Bug

The workflow for resolving security issues in Fedora and EPEL is through the use of bugs in bugzilla. This consists of both a parent bug (usually with one or more CVE names referenced), and tracking bugs that are used to track the fix of the flaws in the affected products.

Red Hat Product Security largely manages the entry of flaw (parent) bugs and will file tracking bugs as appropriate. What follows is an overview of that process.

Suppose a flaw is found in the "yoyodine" package. A member of Red Hat Product Security creates a bug in bugzilla, in the Security Response product, with a component of "vulnerability". If a CVE is already known, it is noted in the bug (by setting the alias and prepending it to the Summary field). If it is not known, a CVE is requested on the oss-security mailing list.

Some of the parent (CVE) bug's attributes include:

  • It is in the "Security Response" product
  • Applicable CVEs are added as bug aliases
  • Applicable CVEs are prefixed to the Summary description
  • Public issues result in public bugs (no group restrictions)
  • It is always assigned to the "Red Hat Security Response Team" user
  • The priority/severity map to the Red Hat impact rating
  • The "Security" keyword is set


Tracking Bugs

During the process of investigation, if it is found that Fedora and/or EPEL are affected by this flaw, Red Hat Product Security will create the tracking bug(s) via the use of a script. If it is later found that the same code exists in another package (although we try not to embed one package in another, it does happen, particularly with libraries), new tracking bugs will be created against that package for the affected products ("xpdf" historically has suffered from this problem).

Some of the tracking bug characteristics include:

  • It depends on the parent bug
  • It is filed against the appropriate Product/Component/Version for the affected package/product
  • It is assigned to the owner of the component
  • Applicable CVEs are prefixed to the Summary description
  • Applicable affected versions are appended to the Summary description (such as "[fedora-all]" or "[epel-6]")
  • The "Security" and "SecurityTracking" keywords are set
  • The initial description and comment(s) of the bug don't describe the flaw(s) but refer the assignee to the parent bug for details/patches/etc, but do indicate how to correct the flaw via established process (either a filled-out template to use with "fedpkg update" or a link to use with Bodhi).

Handling tracking bugs in Bodhi

The maintainer commits the fixes, builds packages and creates an update request. He refers to both parent bug and tracking bug. Bodhi is able to identify that the bug is a tracking bug and doesn't include it in the new package announce mail. Bodhi closes the tracking bug, and in case all other bugs that Parent depends on it also closes the parent. To keep track, Bodhi adds comments to both the parent and the tracking bug.

Note: The comments in the tracking bug provide a link to Bodhi to ease the inclusion of bugs, particularly when there are a large number of parent bugs.

Handling tracking bugs via fedpkg

The maintainer commits the fixes and builds packages and then submits the update to Bodhi via Package_update_HOWTO#Submit_your_update_to_Bodhi.

Note: The comments in the tracking bug (only since July 2014) provide a template that can be used (cut-n-paste) for the "fedpkg update" process.