From Fedora Project Wiki

(Moving information to other pages.)
Line 43: Line 43:
While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely.  But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.
While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely.  But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.


When in doubt, please contact the [mailto:secalert@redhat.com Red Hat Security Response Team].}}
When in doubt, please contact [mailto:secalert@redhat.com Red Hat Product Security].}}


[[Category:Security]]
[[Category:Security]]

Revision as of 16:56, 18 July 2014

Security bugs, in Fedora, generally come from one of two places: people finding them an opening a ticket in Red Hat's Bugzilla instance or Red Hat's Product Security group opening bugs in response to CVEs being made public. Security bugs are sometimes kept private due to an ongoing embargo but we generally do not want a security bug to remain out of the public's sight for too long.

Once a security bug has been filed it is generally left up to Fedora contributors to make sure the issue is fixed within Fedora. That process is explained below.

What are Security Bugs?

CVE Bugs

When Red Hat Product Security creates a CVE bug that affects Fedora a tracker bug should also be opened explicitly against the package where the vulnerability is found. There may be follow up on the tracker bug but if the package is only shipped in Fedora and/or EPEL and not RHEL there may not be any additional feedback from Red Hat.

Non-CVE Bugs

There may be times when someone within the community finds a potential security bug and submits a bug against the package. When this happens, and the bug is properly tagged as a security issue, Red Hat Product Security will likely follow up and evalutate the issue against current CVE criteria. Once this happens we'll likely see a process as explained with CVE bugs.

Priority of CVEs

CVEs are assigned one of four priorities depending on the severity and impact:

  • Critical
  • Important
  • Moderate
  • Low

Resolving security bugs

The Fedora Security Team's mission, in this case, is to help steer security bugs that affect Fedora towards a successful resolution. That means, if necessary, taking control of the process and making sure that patches get shipped.

Working with upstream

Some security bugs will come with patches that do not come from upstream. If this is the case we should make contact with upstream, opening bugs a needed upstream, and work with them to confirm the vulnerability and if the patch fixes the issue.

Shipping the fix

If the patch comes from upstream we should test the patch with the current package and verify it builds. If so, we should work with the packager to ship the patch, closing the tracker bug using Bodhi. If the fix comes from upstream as a new version then shipping that version should go through the same process, closing the tracker bug with Bodhi.

If the packager does not respond in a timely manner then involving FESCo should be a priority.

Understanding Security Issues

When filing security bugs, care may need to be taken regarding the information being placed in public view. We are in support of the full public disclosure of security issues, but it should be done so in a responsible manner. This primarily applies to embargoed issues.

Idea.png
Please see the Security Classifications page for more information regarding what qualifies as a security issue, and how to file a bug.

Embargoed Security Issues

An embargoed security issue is one which is not publically known, and its existence is to be reported to responsible organizations. Often when a researcher discovers a security issue, they will contact an organization such as vendor sec or the project's upstream developers. If the issue is of great severity, it is wise to give the upstream project, various distribution vendors, and the researcher some time to produce patches and advisories for the issue. That means setting a date sometime in the future which all parties can agree upon.

When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" checkbox to ensure that the information being entered is not publically viewable until the embargo date passes. These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.

Important.png

While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely. But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.

When in doubt, please contact Red Hat Product Security.