From Fedora Project Wiki

m
m
Line 4: Line 4:
 
== How ==
 
== How ==
 
Fedora Security Team aims to ensure that users are protected from any vulnerabilities that exist in Fedora packages. The vulnerabilities are reported to Fedora package maintainers via [https://bugzilla.redhat.com/ Bugzilla].
 
Fedora Security Team aims to ensure that users are protected from any vulnerabilities that exist in Fedora packages. The vulnerabilities are reported to Fedora package maintainers via [https://bugzilla.redhat.com/ Bugzilla].
These bugs are marked with '''keywords: security''' attribute in Bugzilla, for ex. => [https://bugzilla.redhat.com/show_bug.cgi?id=838761 ndjbdns vulnerable to cve-2012-1191(ghost domain attack)]. The package maintainer then follows up with the upstream developers to obtain a patch or a new release which fixes the issue. Once such patch or a new release is available, package maintainer then builds a new version of the Fedora package and submits an update to the Fedora repositories via [https://admin.fedoraproject.org/updates/ Bodhi].
+
These bugs are marked with '''keywords: Security''' attribute in Bugzilla, for ex. => [https://bugzilla.redhat.com/show_bug.cgi?id=838761 ndjbdns vulnerable to cve-2012-1191(ghost domain attack)]. The '''Security''' keywords indicates that the bug could have security implications which need to be investigated. The package maintainer then follows up with the upstream developers to obtain a patch or a new release which fixes the issue. Once such patch or a new release is available, package maintainer then builds a new version of the Fedora package and submits an update to the Fedora repositories via [https://admin.fedoraproject.org/updates/ Bodhi].
  
It is a fairly straight forward process. But the problems arise when package maintainers either don't understand the issue or are too busy to triage it in time. That is where the Fedora Security Team comes in to help. We work with the upstream developers to obtain the security fixes and help packager maintainers to push these fixes to the Fedora repositories.
+
It is a straight forward process. But the problems arise when package maintainers either don't understand the issue or are too busy to triage it in time. That is where the Fedora Security Team comes in to help. We work with the upstream developers to obtain the security fixes and help package maintainers to push these fixes to the Fedora repositories.
  
 
=== [https://cve.mitre.org/ CVE] ===
 
=== [https://cve.mitre.org/ CVE] ===
  
CVE stands for '''Common Vulnerabilities and Exposures'''. It is the global standard used to uniquely identify and track information security vulnerabilities. Each vulnerability in any package has a unique CVE ID assigned to it. If it is a new issue, we need to [http://www.openwall.com/lists/oss-security/2014/09/07/1 request] a CVE ID for it from [http://www.openwall.com/lists/oss-security/ oss-security] list. The CVE ID is allocated by the [http://www.mitre.org/about/corporate-overview MITRE Corporation], which is the primary '''CVE Numbering Authority(CNA)'''.
+
CVE stands for '''Common Vulnerabilities and Exposures'''. It is the global standard to uniquely identify and track information security vulnerabilities. Each vulnerability in any package has a unique CVE ID assigned to it. If it is a new security issue, we need to [http://www.openwall.com/lists/oss-security/2014/09/07/1 request] a CVE ID for it from the [http://www.openwall.com/lists/oss-security/ oss-security] mailing list. CVE ID are allocated by the [http://www.mitre.org/about/corporate-overview MITRE Corporation], which is the primary '''CVE Numbering Authority(CNA)'''.
  
For each assigned CVE, we create two bugs. First is the parent bug which describes the issue in human understandable details. Second is the child bug which is used to track fixes in individual products(Fedora, Fedora-EPEL etc.), that ship the vulnerable package. Parent bug is generic one; it is opened against '''Component: vulnerability'''. Child bugs are specific, they are opened against '''Component: <package-name>''' and are marked with '''keywords: SecurityTracking'''.
+
For each assigned CVE, we create two bugs. First is the parent bug which describes the issue in human understandable details and lists available fixes. Second is the child bug which is used to track progression of these fixes into individual products(Fedora, Fedora-EPEL etc.), which ship the vulnerable package. Parent bug is a generic one; it is opened against '''Component: vulnerability'''. Child bugs are specific; they are opened against '''Component: <package-name>''' of an individual product and are marked with '''keywords: SecurityTracking'''.
  
 
=== Work flow ===
 
=== Work flow ===
Line 25: Line 25:
 
# Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
 
# Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
 
# GOTO 1;
 
# GOTO 1;
 
  
 
== Taking ownership of tracking bugs ==
 
== Taking ownership of tracking bugs ==
  
Each tracking bug we work on should have a person who owns it for several reasons. It would certainly be inefficient if the work was done twice, and collisions and misunderstandings might occur if two people tried to coordinate fix with upstream and packagers independently. For these reasons, we should indicate the fact we are working on the tracking bug by filling the Whiteboard of the bug with bugzilla login of the owner:
+
Each tracking bug should have an owner for several reasons. It would certainly be inefficient if the work was done twice and collisions and misunderstandings might occur if two people tried to coordinate fix with upstream and packagers independently. For these reasons, we should indicate the fact we are working on the tracking bug by filling the Whiteboard of the bug with bugzilla login of the owner:
  
 
     Whiteboard: fst_owner=<owner>,[<owner2>,<owner3>]
 
     Whiteboard: fst_owner=<owner>,[<owner2>,<owner3>]

Revision as of 15:07, 18 September 2014

Mission

   To provide utmost secure operating environment to the Fedora users.

How

Fedora Security Team aims to ensure that users are protected from any vulnerabilities that exist in Fedora packages. The vulnerabilities are reported to Fedora package maintainers via Bugzilla. These bugs are marked with keywords: Security attribute in Bugzilla, for ex. => ndjbdns vulnerable to cve-2012-1191(ghost domain attack). The Security keywords indicates that the bug could have security implications which need to be investigated. The package maintainer then follows up with the upstream developers to obtain a patch or a new release which fixes the issue. Once such patch or a new release is available, package maintainer then builds a new version of the Fedora package and submits an update to the Fedora repositories via Bodhi.

It is a straight forward process. But the problems arise when package maintainers either don't understand the issue or are too busy to triage it in time. That is where the Fedora Security Team comes in to help. We work with the upstream developers to obtain the security fixes and help package maintainers to push these fixes to the Fedora repositories.

CVE

CVE stands for Common Vulnerabilities and Exposures. It is the global standard to uniquely identify and track information security vulnerabilities. Each vulnerability in any package has a unique CVE ID assigned to it. If it is a new security issue, we need to request a CVE ID for it from the oss-security mailing list. CVE ID are allocated by the MITRE Corporation, which is the primary CVE Numbering Authority(CNA).

For each assigned CVE, we create two bugs. First is the parent bug which describes the issue in human understandable details and lists available fixes. Second is the child bug which is used to track progression of these fixes into individual products(Fedora, Fedora-EPEL etc.), which ship the vulnerable package. Parent bug is a generic one; it is opened against Component: vulnerability. Child bugs are specific; they are opened against Component: <package-name> of an individual product and are marked with keywords: SecurityTracking.

Work flow

If you wish to help make Fedora a secure operating environment, these steps shall come handy

  1. Select an open security bug from -> Open issues.
  2. Own the bug.
  3. Examine the bug details and validate if it is really a security issue.
  4. Determine if a fix is available and if the vulnerability is already fixed in Fedora by examining the current version and/or talking with the package maintainer.
  5. If a fix is not available, work with the upstream developers via email/mailing list/IRC channels to obtain a patch or new version which fixes the issue.
  6. Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
  7. GOTO 1;

Taking ownership of tracking bugs

Each tracking bug should have an owner for several reasons. It would certainly be inefficient if the work was done twice and collisions and misunderstandings might occur if two people tried to coordinate fix with upstream and packagers independently. For these reasons, we should indicate the fact we are working on the tracking bug by filling the Whiteboard of the bug with bugzilla login of the owner:

   Whiteboard: fst_owner=<owner>,[<owner2>,<owner3>]

As <owner> FAS ID should be used, as it simplifies further management.. For the list of bugzilla logins of Fedora Security Team see the Security Team Roster.

For multiple FST owners FAS IDs should be comma-separated and NOT contain spaces.

IRC Channel #fedora-security-team[?]
#fedora-security[?]
Mailing List security-team - Security Team mailing list
security - General security mailing list (good for questions)
Meetings Schedule and Agenda
Current issues Critical Vulnerabilities - Unowned
Important Vulnerabilities - Unowned
Moderate Vulnerabilities - Unowned
Low Vulnerabilities - Unowned
Unknown Vulnerabilities - Unowned
Bugs in MODIFIED, ON_DEV, ON_QA states - Unowned

Hall of Fame

Getting Involved

Getting involved in the FST is easy. First, subscribe to the security-team mailing list. Next, join us in the #fedora-security-team[?] IRC channel. Finally, read the work flow and jump in. If you have questions please asking them on IRC or on the list.