Security process¶

If you need to report a potential security issue, please email foreman-security@googlegroups.com (a private address) immediately so we can help investigate it.

Please see http://theforeman.org/security.html for up to date information on known vulnerabilities and fixes. This page is a development/triage resource only.

foreman-security list¶

The foreman-security mailing list is an invite-only group of Foreman developers, distribution maintainers and security response experts. At the time of writing, it has nine members, which for obvious reasons, we try to keep at a minimum.

The responsibility of the group is to triage incoming notifications from the public and other Foreman developers, analyse and write up the issue, assign a CVE identifier, and to ensure the fix is shipped correctly. It isn't the responsibility of the security team to write the fix/patch.

When a vulnerability is found in a third party component that the project ships, the group should notify them of the vulnerability and help them handle it. For plugins the responsibility of releasing falls to the maintainer(s) instead of the regular Foreman release manager(s).

Vulnerability process¶

When an issue is reported, the following process should be followed by one or more people on the foreman-security list.

1. Reporter emails foreman-security@googlegroups.com with information about the issue.
2. Security team member replies to the reporter, CCing the list to acknowledge the report.
3. Security team member investigates the issue and if invalid, replies to the reporter and list to reject it.
4. If the report is valid, the security team member should judge the severity or email the list to decide on it.
   • Higher/critical severity issues will be embargoed.
   • Lower/medium severity issues will be handled in public as regular bug reports, but with a CVE assigned.
5. Determine the affected versions of Foreman through code analysis, if possible.

For unembargoed/public issues:

1. Security team files a Redmine issue with all relevant details and reproducer information.
   • Set Category to Security
   • Set Release to the next minor/major depending on severity.
2. Reply to the reporter and list to provide the ticket URL and inform them on how it's being handled.
3. The Redmine ticket can be picked up and worked as usual.
   • Consider emailing foreman-dev to help get a developer assigned to the ticket.
4. Email secalert@redhat.com (Red Hat Security Response Team), CCing foreman-security, providing all relevant details and requesting a CVE identifier (if not done under embargo already). Expect a response within 48 working hours.
5. On receiving a CVE identifier:
   1. Update the security webpage with details.
   2. Prefix the Redmine ticket title with the CVE identifier.
6. On merge of the patch, email oss-security@lists.openwall.com with a brief description and links to the ticket and patch

For embargoed issues, handle in a similar way with these exceptions:

1. Take extreme care to make no public comments, emails, pull requests or IRC conversations on the subject. Ensure anybody working on the issue follows the same.
2. Email secalert@redhat.com (Red Hat Security Response Team), CCing foreman-security, providing all relevant details and requesting a CVE identifier. Expect a response within 48 working hours.
   • Use GPG-encrypted email with the key 0x650D5882 (9273 2337 E5AD 3417 5265 64AB 5E54 8083 650D 5882
     )
3. Decide a suitable unembargo date (often ~2 weeks) when it would also be suitable to make a release of Foreman.
4. File a Redmine issue, but set the Private flag which makes the ticket visible to security team members and Redmine administrators.
5. Attach proposed patches to the Redmine issue, review in comments preferably. Don't use private comments.
6. On unembargo, change the Private flag of the Redmine ticket to false. Submit the patch as a pull request and/or merge if tests are green.
7. Have the release manager of the current stable branch(es) make a patch release.