path: root/support/security/vulnerability-treatment-policy.html

---
title: 'Gentoo Vulnerability Treatment Policy'
navtitle: 'Vulnerability Treatment Policy'
nav1: support
nav2: security
nav3: security-vtp
nav3-show: true
nav3-weight: 10
layout: page-nav3
body_class: nav-align-h2
---

<h2>Scope</h2>

<h3>Supported architectures</h3>
<p>
  Gentoo Linux is offered on many different architectures.
  Some of these architectures have more developers than others and, as such, are able to respond to new security vulnerabilities more quickly.
  While the ultimate goal of the Gentoo Security project is to ensure that all architectures receive security fixes at the same time,
  we must also balance that against releasing security fixes and GLSAs as quickly as possible so that the majority of our users are informed and protected.
</p>

<p>
  For this reason, the Security Team separates Gentoo architectures into two groups, <strong>supported</strong> and <strong>unsupported:</strong>
</p>

<dl>
  <dt>Supported</dt>
  <dd>these architectures must have a stable fix committed before the GLSA can be released</dd>
  <dt>Unsupported</dt>
  <dd>these architectures will be notified of new vulnerabilities (cc on relevant bugs), however, we will not wait for a stable fix on these arches before issuing the GLSA and closing the bug</dd>
</dl>

<p>
  Here is the list of currently supported architectures: <strong>alpha, amd64, hppa, pcc, ppc64, sparc, x86.</strong>
</p>

<p>
  All architectures are welcome and encouraged to become a supported architecture.
  There are two straightforward criteria that need to be met in order to be officially supported by the Gentoo Security project:
</p>

<ul>
  <li>
    Appoint a developer who is the primary point of contact for security issues (Architecture Security Liaison) related to your arch:
    This person is responsible for ensuring that security bugs are adequately remediated on their particular architecture.
  </li>
  <li>
    Agree to adhere to the published timelines for testing and marking packages as stable.
  </li>
</ul>

<h3>Kernels</h3>
<p>
  Kernels are not covered by the GLSA release process.
  Vulnerabilities must still be reported and will be fixed, but no GLSA will be issued when everything is solved.
</p>

<h3>Non-stable packages</h3>
<p>
  Sometimes a vulnerability is found in a package that is not part of the stable trees.
  This is the case when the vulnerability is a security regression in a newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when the package has never had any stable ebuilds in the tree.
  In this case the vulnerability must still be reported and will be fixed, but no GLSA will be issued when everything is solved.
</p>

<div class="alert alert-info">
  <strong>Note:</strong> This policy might be changed when our tools support more complex upgrade paths and if a sufficient number of GLSA coordinators join the Security Team.
</div>

<h2>Vulnerability Feed</h2>

<h3>Published vulnerabilities</h3>
<p>
  Each vulnerability should initially be entered as a <a href="https://bugs.gentoo.org">Bugzilla</a> entry with product "Gentoo Security" and component "Vulnerabilities" (assigned to <a href="mailto:security@gentoo.org">security@gentoo.org</a>).
  Major security lists should have official scouts assigned to them which should ensure that all vulnerabilities announced on these lists get a security Bugzilla entry.
</p>

<h3>Confidential vulnerabilities</h3>
<p>
  Confidential vulnerabilities (for example coming from developer's direct communication or restricted lists) must follow a specific procedure.
  They should not appear as a public bugzilla entry, but only in security-restricted media like a private bugzilla section or the GLSAMaker tool.
  They should get corrected using private communication channels between the GLSA coordinator and the package maintainer.
</p>

<div class="alert alert-info">
  <strong>Note:</strong>
  Communication for confidential vulnerabilities should be properly encrypted.
  They should be sent to specific Security Team members and encrypted with their GPG key.
  The list of the Security Team members is available on the  <a href="https://wiki.gentoo.org/wiki/Project:Security">project page</a>,
  their key IDs can be looked up on the <a href="/inside-gentoo/developers/">Gentoo Linux Developers List</a>
  and their keys can be retrieved from the <a href="http://subkeys.pgp.net:11371">subkeys.pgp.net</a> keyserver.
  The use of IRC and other unencrypted messaging methods is discouraged.
</div>

<h2>Dispatch</h2>

<h3>Severity Level</h3>
<p>
  In order to seed the appropriate reaction times and escalation procedures, we need to assign a severity level to each vulnerability.
  This severity level must be based on how widespread the affected software is amongst Gentoo users and depth of the vulnerability.
</p>

<p>
You can use the following two tables to help you assign the severity level:
</p>

<table class="table table-condensed">
  <tr>
    <th>How widespread the package is</th>
    <th>Configurations affected</th>
    <th>Severity Component</th>
  </tr>
  <tr>
    <td>System package</td>
    <td>Default or specific</td>
    <td><code>A</code></td>
  </tr>
  <tr>
    <td rowspan="2">Common package (supposed present on at least 1/20 Gentoo installs)</td>
    <td>Default</td>
    <td><code>A</code></td>
  </tr>
  <tr>
    <td>Specific</td>
    <td><code>B</code></td>
  </tr>
  <tr>
    <td rowspan="2">Marginal software (supposed present on less than 1/20 Gentoo installs)</td>
    <td>Default</td>
    <td><code>B</code></td>
  </tr>
  <tr>
    <td>Specific</td>
    <td><code>C</code></td>
  </tr>
  <tr>
    <td>Package that never had an affected version stable</td>
    <td>Default or Specific</td>
    <td><code>~</code></td>
  </tr>
</table>

<table class="table table-condensed">
  <tr>
    <th>Evaluate the vulnerability type</th>
    <th>Severity Component</th>
    <th>Corresponding GLSA severity</th>
  </tr>
  <tr>
    <td>Complete remote system compromise: remote execution of arbitrary code with root privileges</td>
    <td><code>0</code></td>
    <td>high</td>
  </tr>
  <tr>
    <td>Remote active compromise: direct remote execution of arbitrary code with reduced or user rights on a server</td>
    <td><code>1</code></td>
    <td>high</td>
  </tr>
  <tr>
    <td>Local privilege escalation: flaw allowing root compromise when you have local access</td>
    <td><code>1</code></td>
    <td>high</td>
  </tr>
  <tr>
    <td>Remote passive compromise: remote execution of arbitrary code by enticing a user to visit a malicious server or using malicious data</td>
    <td><code>2</code></td>
    <td>normal</td>
  </tr>
  <tr>
    <td>Global service compromise: Denial of Service, passwords, full database leaks, data loss (symlink attacks)</td>
    <td><code>3</code></td>
    <td>normal</td>
  </tr>
  <tr>
    <td>Others: Cross-Site Scripting, information leak...</td>
    <td><code>4</code></td>
    <td>low</td>
  </tr>
</table>

<p>
  Here is the table of the resulting severity levels.
  They should be set to the Bugzilla severity level of the same name:
</p>

<table class="table table-condensed">
  <tr>
    <th>Severity level</th>
    <th>Corresponding evaluations</th>
    <th>Target delay</th>
    <th>GLSA</th>
  </tr>
  <tr>
    <td>Blocker</td>
    <td><code>A0</code>, <code>B0</code></td>
    <td>1 day</td>
    <td>yes</td>
  </tr>
  <tr>
    <td>Critical</td>
    <td><code>A1</code>, <code>C0</code></td>
    <td>3 days</td>
    <td>yes</td>
  </tr>
  <tr>
    <td>Major</td>
    <td><code>A2</code>, <code>B1</code>, <code>C1</code></td>
    <td>5 days</td>
    <td>yes</td>
  </tr>
  <tr>
    <td>Normal</td>
    <td><code>A3</code>, <code>B2</code>, <code>C2</code></td>
    <td>10 days</td>
    <td>yes</td>
  </tr>
  <tr>
    <td>Minor</td>
    <td><code>A4</code>, <code>B3</code>, <code>B4</code>, <code>C3</code></td>
    <td>20 days</td>
    <td>?</td>
  </tr>
  <tr>
    <td>Trivial</td>
    <td><code>C4</code>, <code>~0</code>, <code>~1</code>, <code>~2</code>, <code>~3</code>, <code>~4</code></td>
    <td>40 days</td>
    <td>no</td>
  </tr>
</table>

<div class="alert alert-info">
  <strong>Note:</strong> The delay indicated in this table is what we want to be the maximum time between the release of a fix by the upstream package developer and the release of a stable ebuild and corresponding GLSA.
</div>

<h3>Security Bug Wrangler role</h3>
<p>
  Someone should assume the responsibility of security bug wrangler and do the following tasks as soon as a new vulnerability enters <a href="https://bugs.gentoo.org">Bugzilla</a>:
</p>

<ul>
  <li>checking for duplicates: if the bug describes a vulnerability already reported it should be resolved as DUPLICATE</li>
  <li>checking for wrong component: if the bug is not about a vulnerability its component should be changed appropriately</li>
  <li>checking if the bug is really a vulnerability and that it affects a Gentoo Linux package, otherwise resolve the bug as INVALID</li>
</ul>

<p>
  During this phase it may be necessary to ask the reporter for details.
  The bug remains with status UNCONFIRMED or CONFIRMED as long as necessary.
  When (if) the bug passes these sanity tests, it should be marked as IN_PROGRESS and the bug wrangler should do the following:
</p>

<ul>
  <li>rename the bug so that it includes category/package-name at start (for example: <em>net-mail/clamav: DoS using RAR files</em>)</li>
  <li>remove version information in the bug title if there is no fixed version available. Bug titles like <em>&lt;=category/package-1.2.3</em>, where 1.2.3 is the latest version of the package, should be avoided.</li>
  <li>evaluate and assign a severity level (see above)</li>
  <li>set the status to IN_PROGRESS</li>
  <li>seed the status whiteboard to the correct severity code and status</li>
  <li>cc package maintainers to the bug according to package metadata</li>
  <li>set the URL field to an upstream bug or similar</li>
  <li>search for a reserved or assigned CVE identifier and add it to the bug title, request a CVE otherwise</li>
  <li>enter the bug number in the CVE tracker (given the wrangler has access to it)</li>
  <li>set the Alias field to the CVE identifier. In case there are multiple identifiers, use the first one.</li>
</ul>

<div class="alert alert-danger">
  <strong>Warning:</strong> You should not change bug severity once it has been assigned. If you want to increase developer awareness that a bug needs care, use the Priority field instead.
</div>

<h3>Timeframe and backup procedures</h3>
<p>
  This dispatch has to be done quickly after bug creation in order to seed short delays for major vulnerabilities and to show appreciation to the bug reporter.
  The target delay is 12 hours.
  The security bug wrangler has to maintain a list of possible GLSA coordinators with availabilities and preferred areas of expertise. In order to ensure permanent dispatch, the security bug wrangler job should have appropriate back-ups.
</p>

<h2>Bug correction and GLSA draft</h2>

<h3>GLSA Coordinator role</h3>
<p>
  The GLSA coordinator has responsibility for the following tasks:
</p>

<ul>
  <li>determine what must be done in order to close the vulnerability (for example identify the upstream version containing the fix)</li>
  <li>if no fix is available from upstream yet, ensure that the bug is correctly reported to the upstream developer and set status whiteboard to <code>upstream</code></li>
  <li>if a fix is available, get the package maintainer involved to produce and commit an ebuild containing the fix and set status whiteboard to <code>ebuild</code></li>
  <li>once an ebuild is committed, evaluate what keywords are needed for the fix ebuild
  and get arch-specific Teams to test and mark the ebuild stable on their architectures (arch teams should be cc'd on the bug, as well as releng during release preparation) and set status whiteboard to <code>stable</code></li>
  <li>arch-maintainers should mark the ebuild stable if there is no regression in the fix ebuild compared to the latest vulnerable version</li>
  <li>in parallel, writing a draft GLSA using the GLSAMaker tool</li>
  <li>when the corrective ebuild is ready for all supported archs, set the status whiteboard to <code>glsa</code></li>
</ul>

<div class="alert alert-info">
  <strong>Note:</strong> If the bug makes progress and the assigned GLSA coordinator does not react, the other members of the Security Team can help keeping the bug rolling by updating its status.
</div>

<h3>Timeframe and escalation procedures</h3>
<p>
  In order to meet the target delay for vulnerability resolution, a number of escalation procedures have been defined. These include:
</p>

<ul>
  <li>when a bug in a waiting state needs urgent care, you should change the status whiteboard entries to their "+" counterpart: <code>upstream+</code>, <code>ebuild+</code>, <code>stable+</code> and <code>glsa+</code></li>
  <li>
    if no upstream fix is available (<code>upstream+</code> status), a decision must be taken on masking the package:
    The Security Team can mask a package which is not depended on by itself, maintainers should be consulted before masking a package which is not standalone
  </li>
  <li>if the maintainer/herd does not show up for producing the ebuild during 48 hours after summoning (<code>ebuild+</code> status), the Security Team should try to bump the ebuild by itself</li>
  <li>
    if testing and marking stable takes too much time (<code>stable+</code> status), the Security Team will shout on IRC channels and gentoo-dev list to get more testers.
    It will either mark the ebuild stable by itself or, in the event this cannot be done due to stability issues, mask it (see security masking approval policy above)
  </li>
  <li>if the GLSA coordinator does not show up to draft a GLSA (<code>glsa+</code>status), then another member of the Security Team should draft the GLSA and submit it to peer review</li>
</ul>

<h3>Good practices for security bugs</h3>
<p>
  Security bugs differ from other bugs, in that an easy and simple upgrade path must be presented to users through the GLSA. Therefore package maintainers and GLSA coordinators should follow these good practices:
</p>

<ul>
  <li>The ebuild including the security fix should have its own version number, so that it gets picked up in the normal system upgrade process: use rev-bumps if needed</li>
  <li>The ebuild including the security fix should have a higher version number than any previously published version, so that an easy upgrade path can be proposed to the user</li>
  <li>In case of a patch, it should only be applied to the more recent version, there is no need to rev-bump all ebuilds with a patched version</li>
  <li>Vulnerable versions should be left in the tree until the bug enters the <code>stable</code> status, in order to correctly evaluate what keywords are needed for the fix version</li>
</ul>

<h2>GLSA Publication Process</h2>

<h3>Peer review</h3>
<p>
  Once ready, a GLSA should be submitted to peer review.
  At least two members of the Security Team must approve the draft GLSA. Once the draft passes the peer review process, it should be assigned an official GLSA number.
</p>

<h3>GLSA release</h3>
<p>
  Once the GLSA passes the peer review process (and after making sure the ebuild has made its way into the stable tree), the GLSA coordinator should commit the GLSA XML in the Gentoo CVS repository.
  Once this is done, the GLSA will automatically appear on the <a href="https://security.gentoo.org/glsa/">official GLSA index page</a> and <a href="https://security.gentoo.org/glsa/feed.rss">RSS feed</a>.
</p>

<h3>GLSA publication</h3>
<p>
  The GLSA text version must be published by the GLSA coordinator to the following media:
</p>

<table class="table table-condensed">
  <tr> 
    <th>Gentoo Linux official announcement mailing-list</th>
    <td><a href="mailto:gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</a></td>
  </tr>
  <tr>
    <th>Gentoo Linux announcement forum</th>
    <td><a href="https://forums.gentoo.org/viewforum.php?f=16">http://forums.gentoo.org/viewforum.php?f=16</a></td>
  </tr>
</table>

<p>
  There should be one single email sent, with the following rules:
</p>

<ul>
  <li>The <code>To:</code> field must be set to gentoo-announce</li>
  <li>The <code>From:</code> and <code>Return-Path:</code> must be set to the GLSA coordinator @gentoo.org address</li>
  <li>The <code>Subject:</code> field must be "[ GLSA XXXXYY-ZZ ] Your vulnerability here"</li>
  <li>The body should only contain the text version of the GLSA</li>
  <li>The email must be signed by the GLSA coordinator GPG key</li>
</ul>

<div class="alert alert-info">
  <strong>Notes:</strong><br>
  Developer key IDs can be found on the Gentoo Linux <a href="/inside-gentoo/developers/">Developer list</a>. All the Security Team GPG keys are published on public key servers, including (but not limited to) <a href="http://subkeys.pgp.net:11371">subkeys.pgp.net</a>.<br>

  To minimize errors in the publication process, the forum publication step is handled by an automatic poster when it receives the announcement.<br>

  Starting Feb 2, 2012, we have decied to no longer CC any third parties.
  The gentoo-announce mailing list has little other traffic, so that they should be subscribed there.
  General security mailing lists such as full-disclosure or bugtraq are not our target audience, and having various distributions send notices about the same issues is not of any use to most readers there, they too should be on gentoo-announce.
</div>

<p>
  When the GLSA has been published the corresponding bugzilla bug should be resolved as FIXED, with the GLSA number referenced in the comments section of the bug.
  GLSAMaker 2 offers this option after releasing the advisory.
</p>

<h3>GLSA Errata</h3>
<p>
  Sometimes an error will slip through the peer-review process and an incorrect GLSA will be published to the world. Depending on the severity of the error(s), the following policy for erratum should be applied:
</p>

<table class="table table-condensed">
  <tr>
    <th>GLSA error type</th>
    <th>Erratum action</th>
  </tr>
  <tr>
    <td>Typos: presentation, grammar or syntax errors</td>
    <td>Do nothing</td>
  </tr>
  <tr>
    <td>Error in title: title is about another package or does not describe the vulnerability correctly</td>
    <td>An erratum GLSA should be published, replacing the erroneous one</td>
  </tr>
  <tr>
    <td>Error in description: the problem is not described correctly</td>
    <td>The GLSA XML should be corrected, no publication</td>
  </tr>
  <tr>
    <td>Omission: GLSA is correct but incomplete, you also need to update another package to get protection from that vulnerability</td>
    <td>A separate GLSA should be issued on the other vulnerable package</td>
  </tr>
  <tr>
    <td>Error in affected/unaffected versions number, but people using stable packages and applying GLSA instructions are protected anyway</td>
    <td>The GLSA XML should be corrected, no publication</td>
  </tr>
  <tr>
    <td>Error in affected/unaffected versions number, people applying GLSA instructions are not at all protected</td>
    <td>An erratum GLSA should be published, replacing the erroneous one</td>
  </tr>
</table>