| NEWS: (updated 2008-09-30) Infrastructure status | New SSH fingerprints | New package signing key |
Extras/Schedule/SecurityPolicy
From FedoraProject
We need a Security Policy for Extras. For Details see this Thread: https://www.redhat.com/archives/fedora-maintainers/2006-January/msg00050.html
See also: List of open security bugs in Fedora
Contents |
Mission
To work towards the goal of maintaining a high level of security throughout Fedora Extras. We plan to do this by collecting and distilling security information from sources like Bugtraq and Vendorsec, assisting packagers in fixing security issues and, if necessary, fixing security issues when the maintainers are unavailable or inactive.
We recognize that despite Core's quick development rate and short EOL cycle and the Extras "no QA" development method, Extras packages will find their way onto servers and thus Extras security must be taken seriously. We also recognize that Extras maintainers have significant leeway with their packages and do not wish to overburden them with excessive structure and bureaucracy.
Statement of Problem
There really are 2 distinct problems:
Slow to non existent response to security FE Bugzilla Tickets
The problem mentioned in the above thread and in threads before that is about package maintainers not / slow responding to security problems entered in bugzilla. A few weeks ago someone made a post to the list with a number of long standing open security bz tickets. As I'm very much interested in FE security (and have volunteered to become part of a securityteam) I've taken a look at some of these bugs with mixed results:
The first one I've looked at is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169791 I've backported the upstream fix to the current FE version as upstream has a new major number, and I've offered to push trough the build for all supported releases. All the maintainer has todo is say go ahead, still no response and this is a security issue!
The second one is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170045 Which I have fixed with permission from the maintainer.
What we need IMHO is:
- a securityteam, which automaticly gets into the CC list of any security rated bug.
- a policy about when the security team can (temporarily) take over the package and fix said bug at their discretion without the package owners permission / communicating with the package owner.
Someone needs to monitor bugtraq and others for potential security problems
Someone needs to monitor bugtraq and others for potential security problems and enter them in bugzilla, thus putting them into the process for which a policy should be defined as a result of problem 1.
This can be partly automated, grab an rss feed, and check if a advisory contains any package names as listed in the bugzilla owners file, this is however ofcourse not 100% proof.
Also, someone needs to apply for inclusion in VendorSec for the Fedora Extras project. This is where embargo security information is disclosed. This person can share the embargo information with the Extras security response team, and the maintainer of a package in question. It is very important that this information is held private and not disclosed. Until such time we have the ability to prepare embargo updates in private with the Extras build system, nothing more than a bugzilla entry (marked private) and private communication regarding patches can be done.
Current Draft Proposal
We propose to the Steering Committee the following:
- The creation of a Security SIG and the designation of at least three active FE-contributers as Security SIG members with the special priviliges described below.
- The creation of two mailing lists for security discussion: fedora-extras-security and fedora-extras-security-private (the latter to be used for discussion of embargoed topics should they arise).
- That all Extras-related Bugzilla issues with a severity of "Security" be automatically CC'd to fedora-extras-security list for public available bugs or to fedora-extras-security-private list for bugs which are marked as private.
- That designated members of the Security SIG be granted the power to commit fixes and request builds for packages once the maintainer is found to be inactive.
- That, developer time permitting, a method of high-priority submission to the build system be set up and for designated Security SIG members be allowed to submit high priority jobs.
- That a mechanism be provided allowing designated Security SIG members request that essential security fixes be signed and pushed to the mirrors on relatively short notice. (We're just asking for a couple of people we can email.)
- That designated Security SIG members be allowed to create branches in the CVS repository. It is expected that this will be an extremely rare event, only necessary when a security problem necessitates a backport of a dependency.
- That members of the Security SIG be allowed to post security announcements somewhere.
- How does one become a designated Security SIG member?
1. subscribe to the fedora-extras-security list (non private version) 2. mingle, communicate, contribute, state your intention / wish to become a (designated) security SIG member 3. repeat 2. 4. someone who already is a designated security SIG member proposes making you one too to FESco. 5. FESco usually follows this proposal 6. You get access to the private list and al the other special "rights" and duties!
- We propose the following basic set of guidelines for choosing a length of time that the team will wait for a response before finding a package owner to be inactive:
| Class of exploit | Wait time |
| Remotely exploitable code execution as root, without requiring user interaction | 24 hours |
| Remotely exploitable code execution as non-root, without requiring user interaction | 48 hours |
| Remotely exploitable code execution as root, requiring non-root user interaction | 72 hours |
| Remotely exploitable code execution as root, requiring root interaction | 96 hours |
| Remotely exploitable code execution as non-root user, requiring user interaction | 96 hours |
| Local privilege escalation (non-root user can get root rights) | 72 hours |
| SQL injection or other (cross-scripting) destructive access to data(base) | 24 hours |
| SQL injection or other (cross-scripting) append access to data(base) | 48 hours |
| SQL injection or other (cross-scripting) read access to data(base) | 72 hours |
| HTML (javascript) -> database -> someone else's browser doing stuff and similar cross scripting attacks | 72 hours |
| System DOS | 48 hours |
| Daemon DOS | 72 hours |
These time frames could be shortened due to embargo date for private security issues if it would mean having an update prepared on the embargo date.
Open Issues
(with the proposal, not open security issues)
- The Extras project as a whole needs a way for a maintainer to designate that they have dropped maintenance of a particular branch. We need this to know if we need to wait for a maintainer.
- We have to talk about embargoes and how we are going to be included in those kinds of things.
- Where are announcements sent? - Updates should be sent to the Fedora-announce-list. This is where Core security package updates are announced.
Modus Operandi
- Security team members casually peruse Bugraq, vendor security lists, even LWN and look for relevant security issues, forwarding them to the security list. Astute team members can do security audits as well.
- When security problems are found, a security rated bugzilla entry for the problem will be created. The purpose is to make the packager aware of the problem and to open a dialog with the packager, to see if the team can be of assistance. The team can present patches if they have them. This is done through bugzilla so things can be tracked.
- Generally the maintainer will push a new package.
- If the maintainer doesn't respond within a yet-to-be-decided time and a fix exists, a member of the security team will update the package and request a build.
