|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| [[File:Fedora_Security_Team.png|200px|right|Fedora Security Team logo]]
| | #REDIRECT [[SIGs/Security]] |
| | |
| == Assisting with Vulnerability Patching ==
| |
| This is the work flow for helping fix security bugs in Fedora and EPEL.
| |
| | |
| # Select an open security bug from -> [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&keywords=Security%2C%20SecurityTracking%2C%20&query_format=advanced Open issues].
| |
| # [[Security_Team_Work_Flow#Bug_Ownership|Own the bug]].
| |
| # Examine the bug details and validate if it is really a security issue.
| |
| # 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.
| |
| # 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. | |
| # Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
| |
| # GOTO 1;
| |
| | |
| If you run into a [[Policy_for_nonresponsive_package_maintainers | nonresponsive package maintainer]] we follow Release Engineering policy to overcome these issues.
| |
| | |
| === 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.'''
| |
| | |
| == Security Response ==
| |
| | |
| The [[Security Team]] helps packagers fix security vulnerabilities in packages they maintain. Most of these vulnerabilities come from the open source software community and packagers are notified by a ticket in [https://bugzilla.redhat.com Bugzilla].
| |
| | |
| TODO
| |
| | |
| == Secure Coding ==
| |
| Secure coding is writing code with security in mind from the beginning. By not making security mistakes the code is more secure and time won't be wasted down the road having to rewrite or redesign features and functionality.
| |
| | |
| === Projects ===
| |
| | |
| ==== Defensive Coding book ====
| |
| | |
| The [https://huzaifas.fedorapeople.org/public/defensive-coding/ Defensive Coding guide] is published on the [https://docs.fedoraproject.org Fedora Docs website] and is [https://fedorahosted.org/secure-coding/ under development]. The purpose of the book is to document common mistakes developers make and help educate developers on how to better their code from the beginning.
| |
| | |
| | |
| ==== Training and Articles ====
| |
| | |
| In addition to the Defensive Coding book the Security SIG is charged with creating training resources. Videos and smaller articles on secure development can also be created to concentrate specific topics. These resources should be stored in the [https://fedorahosted.org/secure-coding/ secure coding] git repository.
| |
| | |
| ==== Security Basics and HOWTO Articles====
| |
| | |
| Basic Fedora security HOWTO is [[SecurityBasics]]
| |
| | |
| == Code Auditing ==
| |
| | |
| | |
| Many security vulnerabilities are found with the help of a code audit. If you are interested in performing an audit please see our [[:Category:Code_Audit|auditing resource]] page.
| |
| | |
| TODO
| |
| | |
| <!--
| |
| | |
| == Mission ==
| |
| | |
| | |
| == Code Audit Procedure ==
| |
| === File request ===
| |
| # [https://fedorahosted.org/secure-coding/newticket Open a ticket]
| |
| # Add code or address to repository to the ticket.
| |
| # Set type and component to ''Code Audit''.
| |
| | |
| === Performing a code audit ===
| |
| # Use the [[Code Audit Report]] as a template for the code audit.
| |
| # Perform the code audit.
| |
| # Post the [[Code Audit Report]] on the ticket and close.
| |
| | |
| -->
| |
| | |
| <!--
| |
| | |
| == Tools/Resources ==
| |
| | |
| * [http://rootkit.nl/projects/lynis.html lynis]
| |
| * [http://www.trapkit.de/tools/checksec.html checksec]
| |
| * [https://docs.fedoraproject.org/en-US/Fedora_Security_Team/html/Defensive_Coding/index.html Defensive coding]
| |
| * [https://fedorahosted.org/scap-security-guide/ SCAP Security Guide]
| |
| * [http://people.redhat.com/sgrubb/security/ Security Assessment Tools/Scripts]
| |
| * [https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Nonresponsive Package Maintainers Policy]
| |
| | |
| -->
| |
| | |
| [[Category:Security Team]]
| |
