Security Team

Fedora Security Special Interest Group (SIG)

Fedora's Security SIG is no separated SIG but it is integrated into the community, and associates and connects contributors and other SIGs that impact security, but also aims to embed security perspectives into other teams and SIGs.

The Security SIG offers a point of exchange and to connect with. It allows users and contributors to have a place where they can go to when it comes to making aware of or discussing security matters, it brings different perspectives in the security discussions together, it embeds security-perspectives into the community and facilitates feedback loops into all areas of Fedora with consolidated security-relevant knowledge.

With the Security SIG as core element, it replaces the former Security Team along with other SIGs and Teams. The Security SIG complements but does not yet replace the Red Hat Product Security.

Contact

The Security SIG has currently two dedicated places to connect and to exchange:

• Matrix channel: #security:fedoraproject.org (Direct Link to Fedora Chat)
• Discourse tag: #security-sig (category Project Discussion in Discourse)

Additionally, experience has shown that the Devel Mailing List has evolved to a major point of exchange and coordination in security matters (e.g., the major point of coordination of the "early hours" of the XZUtils case has become the Devel Mailing List).

Feel free to join the Matrix channel or open a topic with the #security-sig tag in Discourse if there is anything with regards to security you want to discuss, but also consider the Devel Mailing List. The Security SIG is overlapping and intertwined with the Devel Mailing List (so are its contributions).

Some other SIGs with a security emphasis have subordinated themselves within Discourse to the security-tag and have become themselves sub-tags of #security-sig in order to associate themselves with the #security-sig (and thus to connect their debates). So far, these are:

• the #confined-users tag of #security-sig
• the #incident-response tag of #security-sig -> at the moment, the #incident-response SIG/team is to be set up. The tag is monitored by a few Discourse moderators but nothing dedicated yet.

Keep in mind that the communication channels of the Security SIG are public and thus all information shared in these channels is public too. Because the Security SIG is not yet intended to replace the Red Hat Product Security, you might also consider to contact them if your case involves information that should not yet become public (which usually applies if the information can be exploited practically & immediately to conduct attacks against Fedora or other users). Yet, even in such cases, you are encouraged to early let the Security SIG know that you have contacted the Red Hat Product Security because of a given case, without providing information about the case itself.

Getting involved

All users, contributors and SIGs/teams are encouraged to create ties to the Security SIG to introduce a security perspective in their activities and vice versa. Feel free to join the Matrix channel, open a Discourse topic with the respective tag, or if you create a Discourse topic for your own organization, feel free to additionally add a respective tag that is associated with the Security SIG if you would like to get a security perspective about the very matter.

It is also always useful to follow the Devel Mailing List (and contribute if applicable).

If you want to add further sub-tags within the #security-sig in Discourse, feel free to open a topic about it in the Site Help & Feedback category and let the moderators know about your suggestion.

Contact

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

• IRC:
  • #fedora-security^[?] - general security questions
  • #fedora-security-team^[?] - FST IRC channel for working vulnerabilities
• Mailing lists:
  • security - General security mailing list (good for questions)
  • security-team - Security Team mailing list
• Weekly meetings:
  • Every Thursday at 14:00 UTC. -> Schedule and Agenda

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.

Fedora Security Special Interest Group (SIG)

Fedora's Security SIG is no separated SIG but it is integrated into the community, and associates and connects contributors and other SIGs that impact security, but also aims to embed security perspectives into other teams and SIGs.

The Security SIG offers a point of exchange and to connect with. It allows users and contributors to have a place where they can go to when it comes to making aware of or discussing security matters, it brings different perspectives in the security discussions together, it embeds security-perspectives into the community and facilitates feedback loops into all areas of Fedora with consolidated security-relevant knowledge.

With the Security SIG as core element, it replaces the former Security Team along with other SIGs and Teams. The Security SIG complements but does not yet replace the Red Hat Product Security.

Contact

The Security SIG has currently two dedicated places to connect and to exchange:

• Matrix channel: #security:fedoraproject.org (Direct Link to Fedora Chat)
• Discourse tag: #security-sig (category Project Discussion in Discourse)

Additionally, experience has shown that the Devel Mailing List has evolved to a major point of exchange and coordination in security matters (e.g., the major point of coordination of the "early hours" of the XZUtils case has become the Devel Mailing List).

Feel free to join the Matrix channel or open a topic with the #security-sig tag in Discourse if there is anything with regards to security you want to discuss, but also consider the Devel Mailing List. The Security SIG is overlapping and intertwined with the Devel Mailing List (so are its contributions).

Some other SIGs with a security emphasis have subordinated themselves within Discourse to the security-tag and have become themselves sub-tags of #security-sig in order to associate themselves with the #security-sig (and thus to connect their debates). So far, these are:

• the #confined-users tag of #security-sig
• the #incident-response tag of #security-sig -> at the moment, the #incident-response SIG/team is to be set up. The tag is monitored by a few Discourse moderators but nothing dedicated yet.

Keep in mind that the communication channels of the Security SIG are public and thus all information shared in these channels is public too. Because the Security SIG is not yet intended to replace the Red Hat Product Security, you might also consider to contact them if your case involves information that should not yet become public (which usually applies if the information can be exploited practically & immediately to conduct attacks against Fedora or other users). Yet, even in such cases, you are encouraged to early let the Security SIG know that you have contacted the Red Hat Product Security because of a given case, without providing information about the case itself.

Getting involved

All users, contributors and SIGs/teams are encouraged to create ties to the Security SIG to introduce a security perspective in their activities and vice versa. Feel free to join the Matrix channel, open a Discourse topic with the respective tag, or if you create a Discourse topic for your own organization, feel free to additionally add a respective tag that is associated with the Security SIG if you would like to get a security perspective about the very matter.

It is also always useful to follow the Devel Mailing List (and contribute if applicable).

If you want to add further sub-tags within the #security-sig in Discourse, feel free to open a topic about it in the Site Help & Feedback category and let the moderators know about your suggestion.

Bug Ownership

Each tracking bug should have an owner for several reasons. It would certainly be inefficient if the work was done twice. 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

• Open 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

Tools/Resources

• lynis
• checksec
• Defensive coding
• SCAP Security Guide
• Security Assessment Tools/Scripts
• Nonresponsive Package Maintainers Policy