FixingCVEs

Differences between revisions 18 and 19
Revision 18 as of 2011-02-16 19:47:06
Size: 5347
Editor: brad-figg
Comment:
Revision 19 as of 2011-02-16 19:55:41
Size: 6023
Editor: brad-figg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 61: Line 61:
   1. There should be a separate email for each unique patch. If a single patch applies without changes to multiple series then you'd just send one email for that patch.
   1. The subject line of the patches email *must* contain the series that it applies to and the CVE number.
Line 63: Line 65:
<<BR>>
<<BR>>
----------
   1. Personally, I don't mess with trying to merge with the security team's tree. I checkout a new copy of the kernel team tree, make the appropriate changes for the one CVE that i've completed and push those changes back to the kernel teams tree.
   1. The following give you some idea of the commands you need to use to update the tracking data.
   {{{
   STEAM='lp:~ubuntu-security/ubuntu-cve-tracker/master'
   KTEAM='lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team'
Line 67: Line 71:
{{{
STEAM='lp:~ubuntu-security/ubuntu-cve-tracker/master'
KTEAM='lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team'
   To create the branch:
   * bzr branch $KTEAM
Line 71: Line 74:
To create the branch:
* bzr branch $KTEAM
   In tracker branch (this syncing should probably be scripted):
   * bzr pull $KTEAM
   * bzr commit -m "Saving local changes"
   * bzr push $KTEAM
   * bzr missing -q --theirs-only --line $STEAM | tee ../msg
     If ../msg is not empty
     * bzr merge $STEAM
     * bzr commit -m "$(cat ../msg)"
     * bzr push $KTEAM
Line 74: Line 84:
In tracker branch (this syncing should probably be scripted):
* bzr pull $KTEAM
* bzr commit -m "Saving local changes"
* bzr push $KTEAM
* bzr missing -q --theirs-only --line $STEAM | tee ../msg
  If ../msg is not empty
  * bzr merge $STEAM
  * bzr commit -m "$(cat ../msg)"
  * bzr push $KTEAM
   After changing the anything in an active/CVE-* file
   !! WARNING: bzr includes *all* files changed in the branch dir to the commit
   * bzr commit -m "<this is my message to the world>"
   * bzr push $KTEAM
Line 84: Line 89:
After changing the anything in an active/CVE-* file
!! WARNING: bzr includes *all* files changed in the branch dir to the commit
* bzr commit -m "<this is my message to the world>"
* bzr push $KTEAM
   Useful for cleaning up previous commit (commit undone, changes not)
   * bzr uncommit
Line 89: Line 92:
Useful for cleaning up previous commit (commit undone, changes not)
* bzr uncommit
   }}}
Line 92: Line 94:
}}}

'''NOTE:'''

This document is intended to describe the process the Kernel Team uses to work on CVEs. It does not attemp to explain what a CVE is.

Where are the CVEs that need to be worked on?

There are several places where you can find a CVE to work upon. They are:

Security Team

The Security Team's official page of kernel specific CVEs. This page is semi-automatically updated by members of the Security Team. Contact Kees Cook for more information

Kernel Team

This page shows which CVEs are already beeing worked on by someone on the kernel team. It also shows the current progress on the CVE. It is the responsibility of every member of the Kernel Team to keep this spreadsheet up-to-date.

Cookbook

  1. Pick a CVE to work on.
    1. Go to the kernel team's CVE spreadsheet, pick out a CVE to work on and put your username in the "Assignee" column, next to the CVE you picked.

  2. Save the patch to a file.
    1. Go to the cve tracker page (http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html)

    2. Follow the CVE link in the left column for the CVE you are working to the details page.
    3. Follow the link for "Patches: Upstream:" to the upstream git web commit
    4. Click the "patch" link in the top part of the page.
    5. Select "Save As" from your browser and save the patch.
  3. Create a LP bug.
    1. Use the "create-cve-tracker" tool. Note the cve-id is "20xx-xxxx", it does not include the "CVE-" text. For example:
         create-cve-tracker --cve=2010-4079
    2. The bug description should be updated with information taken from the patch commit description.
    3. As you work the bug on each distro series indicate in the appropriate task the relevance of the patch to that series. For example:
      • If the bug has already been applied, mark that series task as "Fix Released".
      • If the patch is not relevant to that series, mark the task as "Invalid".
      • If the patch is valid and has not been applied already (via a stable upstream release) then:
        1. Mark the status as "In Progress"
        2. Mark the importance as the same as the CVE priority
        3. Assign yourself to the task.
  4. Add the Launchpad Bug link to the kernel team's CVE spreadsheet in the Bug Number column for the CVE.

  5. Modify the patch, prior to applying the patch.
    1. Add the buglink to the patch
    2. Add your sob to the patch
    3. Add the CVE number to the Subject line
    4. Add the CVE number to the bug comment body above the buglink
    5. Add the upstream commit from which the patch was either cherry-picked or backported above your s.o.b.
    6. Add a comment if the patch was accepted into one or more stable kernels.
  6. Apply the patch.
    1. Clone a copy of the appropriate series repo.
    2. If the series repo contains a "master-next" branch, that is where you should be working. That contains the most up-do-date set of commits including stable upstream release commits that have been applied since the start of the last Kernel SRU cycle.
    3. Determine if the patch should be applied.
    4. Apply the patch.
         git am <the patch file>
    5. If the patch does not apply cleanly for any reason, create a copy of the original patch file, making whatever necessary changes there. You will want to keep separate patch files for each series.
    6. Do a test build of a kernel with your patch.
    7. If at all possible, boot test the test kernel.
  7. Add the patches to the LP tracking bug as attachments.
  8. Email the patches to the Kernel Team mailing list for review.
    1. There should be a separate email for each unique patch. If a single patch applies without changes to multiple series then you'd just send one email for that patch.
    2. The subject line of the patches email *must* contain the series that it applies to and the CVE number.
  9. Update the Security Team's CVE tracking data for the CVE.
    1. Personally, I don't mess with trying to merge with the security team's tree. I checkout a new copy of the kernel team tree, make the appropriate changes for the one CVE that i've completed and push those changes back to the kernel teams tree.
    2. The following give you some idea of the commands you need to use to update the tracking data.
         STEAM='lp:~ubuntu-security/ubuntu-cve-tracker/master'
         KTEAM='lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team'
      
         To create the branch:
         * bzr branch $KTEAM
      
         In tracker branch (this syncing should probably be scripted):
         * bzr pull $KTEAM
         * bzr commit -m "Saving local changes"
         * bzr push $KTEAM
         * bzr missing -q --theirs-only --line $STEAM | tee ../msg
           If ../msg is not empty
           * bzr merge $STEAM
           * bzr commit -m "$(cat ../msg)"
           * bzr push $KTEAM
      
         After changing the anything in an active/CVE-* file
         !! WARNING: bzr includes *all* files changed in the branch dir to the commit
         * bzr commit -m "<this is my message to the world>"
         * bzr push $KTEAM
      
         Useful for cleaning up previous commit (commit undone, changes not)
         * bzr uncommit

NOTE: Topic branches typically get CVE updates whenever they are rebased against master. For those branches that are not normally rebased against master (such as ti-omap4), then CVEs must be extracted more or less manually from the master branch. Since those patches have already been vetted on the kernel team mailing list, a second round of acknowledgements is not required if they apply cleanly.

Kernel/Dev/FixingCVEs (last edited 2011-05-18 22:25:50 by brad-figg)