Kernel

Differences between revisions 7 and 8
⇤ ← Revision 7 as of 2011-09-13 19:27:29 →
Size: 1791
Editor: kees
Comment:
← Revision 8 as of 2011-09-13 19:39:41 → ⇥
Size: 2581
Editor: kees
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
 * triage
  * find fix
  * find introduction if possible/easy
  * record as lines using "break-fix" in the "Patches_linux:" section		 Handling CVE triage is basically the same here as with standard CVE triage, except that since kernel CVEs tend to take a long time to get from the `oss-security` mailing list into Mitre, it's best to review the mailing list for new CVEs.
 * Triage normally.
 * Attempt to identify the upstream SHAs that fix the CVE.
 * Attempt to identify the upstream SHA that introduced the vulnerability. If it isn't relatively easy, just skip it. Having this isn't required, but makes backporting easier if it is known, and improves the value of future data-mining about when/where CVEs appear in the kernel. If skipped, or predates the Linus git tree, just use "-" for the SHA.
 * In the "Patches_linux:" tag, add one "break-fix" line per SHA fix.
  * For example, if 12345678 introduced the vulnerability, with abcdabcd and efefefef needed to fix it, this would be:
  break-fix: 12345678 abcdabcd
  break-fix: 12345678 efefefef

Code

There are several trees with scripts in them. UCT carries the main CVE tracking and several of the triage and processing scripts. UQT carries validation scripts. kteam contains scripts written by the kernel team, some of which are used for interfacing with UCT and LP.

  • UCT: lp:~ubuntu-security/ubuntu-cve-tracker/master
  • UQT: lp:~ubuntu-bugcontrol/ubuntu-qa-tools/master
  • kteam: git://kernel.ubuntu.com/ubuntu/kteam-tools.git

Workflow

This is the Kernel Stable Release Update Workflow that all the involved teams collaborate on. LP is overloaded to build a release "state machine", managed by a bot.

Security Team Duties

per-CVE

Handling CVE triage is basically the same here as with standard CVE triage, except that since kernel CVEs tend to take a long time to get from the oss-security mailing list into Mitre, it's best to review the mailing list for new CVEs.

  • Triage normally.
  • Attempt to identify the upstream SHAs that fix the CVE.
  • Attempt to identify the upstream SHA that introduced the vulnerability. If it isn't relatively easy, just skip it. Having this isn't required, but makes backporting easier if it is known, and improves the value of future data-mining about when/where CVEs appear in the kernel. If skipped, or predates the Linus git tree, just use "-" for the SHA.
  • In the "Patches_linux:" tag, add one "break-fix" line per SHA fix.
    • For example, if 12345678 introduced the vulnerability, with abcdabcd and efefefef needed to fix it, this would be: break-fix: 12345678 abcdabcd break-fix: 12345678 efefefef

Frequent

  • Check for workflow items needing attention: $UQT/security-tools/kernel-sru-check

Daily

  • UCT merge with kernelteam
  • sync UCT to LP and back
    • see end of $UCT/README for definition of desired state changes

    • bzr update

    • ./scripts/process_cves merge

    • ./scripts/sync-bugs-kernel.py --skip-search --confirm-update

  • sync UCT to USNs (for any CVEs that have changed state, been revoked, etc)

per-proposed-package

  • (this is our part of the kernel update workflow)

  • validate CVEs for USN publication: $UCT/scripts/prepare-kernel-usn -n REL SRC

  • mark workflow item "Fix Released"

per-released-package

  • publish USN for real: $UCT/scripts/prepare-kernel-usn -u REL SRC

SecurityTeam/UpdatePublication/Kernel (last edited 2025-02-24 15:35:08 by rodrigo-zaiden)