From Fedora Project Wiki

(→‎Contact: Reordered IRC channels and added subjects for each)
(→‎How to get involved: Updated the joining the team portion)
Line 38: Line 38:
== How to get involved ==
== How to get involved ==
=== Joining the team ===
=== Joining the team ===
Joining the Fedora Security Team is easy. First, subscribe to the {{fplist|security-team}} mailing list. Second, join us on the {{fpchat|#fedora-security-team}} IRC channel. And third, read the [[Security_Team#Work_Flow|work flow]] and jump in. If you have questions please ask on IRC or on the mailing list.
 
Joining the Fedora Security Team is an easy, three-step process:
# subscribe to the {{fplist|security-team}} mailing list
# join us on the {{fpchat|#fedora-security-team}} IRC channel
# read the [[Security_Team#Work_Flow|work flow]]
 
Once you feel comfortable just jump in and start helping. If you have questions please ask on IRC or on the mailing list.
 
Also, please take a look at the proposed [[Security Team Apprenticeship]] program as this may help answer additional questions.


=== Work Flow ===
=== Work Flow ===

Revision as of 16:32, 24 November 2015

Mission

To provide the utmost secure operating environment to Fedora and EPEL users by:

  • working with packagers to patch and update packages,
  • identifying and helping to improve practices,
  • and answering questions from the community.

Contact

If you need help or assistance with any issue, please feel free to contact the FST members at

Security Response

To report a vulnerability in software please follow the procedure outlined on the Security Bugs page.

To report a security concern within the Fedora Project please email security at fedoraproject dot org.

What we do

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 by Red Hat Product Security. These bugs are marked with keywords: SecurityTracking attribute in Bugzilla, for ex. => CVE-2013-0333 rubygem-activesupport: json to yaml parsing. The SecurityTracking keyword indicates that the bug could have security implications which need to be investigated. The package maintainer should then follow 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, the package maintainer then builds a new version of the package and submits an update to the Fedora or EPEL 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. 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.

CVEs

CVE stands for Common Vulnerabilities and Exposures and is the global standard for uniquely identifying and tracking software 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. Alternatively, we may also request CVEs from Red Hat via secalert@redhat.com. CVE ID are allocated by the MITRE Corporation, which is the primary CVE Numbering Authority(CNA).

For each assigned CVE two bugs are created: one is the parent bug which describes the issue in human understandable details and lists available fixes and a second is the child bug which is used to track progression of these fixes into individual products(Fedora, Fedora-EPEL etc.). The 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.

How to get involved

Joining the team

Joining the Fedora Security Team is an easy, three-step process:

  1. subscribe to the security-team mailing list
  2. join us on the #fedora-security-team[?] IRC channel
  3. read the work flow

Once you feel comfortable just jump in and start helping. If you have questions please ask on IRC or on the mailing list.

Also, please take a look at the proposed Security Team Apprenticeship program as this may help answer additional questions.

Work Flow

  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 bug tracking/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;

You can log your 90-day Security Challenge work in the ethercalc spreadsheet.

If you run into a nonresponsive package maintainer we do follow Release Engineering policy.

Bug Ownership

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

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

As <owner> FAS ID should be used; It simplifies further management. For the list of Bugzilla user names of the Fedora Security Team see the Security Team Roster.

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

Bugzilla Links

Tools/Resources