Archive Security Audits

Registered by Kees Cook

Discuss how to better manage the influx of potentially insecure packages/changes into the devel archive.

Blueprint information

Not started
Jamie Strandboge
Needs approval
Series goal:
Accepted for oneiric
Informational Informational
Milestone target:
milestone icon ubuntu-11.10

Related branches



 * Describe what comes in and how
  * devel
   * source NEW (non-Ubuntu devs, Debian, Ubuntu devs)
   * binary NEW (syncs, new upsream)
  * -security
  * -proposed
  * -updates
  * -backports
  * ppas (not official buildds are native and most ppas are virtual (the few ppas that are native have acls for Canonical)
 * everything coming in is signed and has an LP acl
 * it is relatively easy to identify and revert uploads from compromised account
* Known problems
 * PPAs: complete trust in individual/teams (ie, typically no peer review) (but signed)
  * vetting process for teams is varied
 * -updates/-proposed
  * lots of people can upload
  * uploads are not built without human review
  * uploads not published to -updates without human review/testing
 * -security
  * ppas limited to team
  * publication is straight to users
  * publication to pocket limited to team and a few other teams
 * devel
  * lots of people can upload (~180)
  * lots of changes coming in
  * MIR provide relatively high level review
  * REVU provides review for non-Ubuntu devs
  * ubuntu-archive provides packaging/licensing review of source NEW
 * several high value targets
* Ideas for addressing the problems and automation (create debdiffs from the changes list and email to security? LP emails?)
 * changes (soyuz)
  * diffstat
  * hotlink to debdiff
  * verify link to the package version in LP
  * UDD won't help
   * doesn't show true state of the package archive
  * autos-syncs don't show up on changes list
 * 2-factor authentication for high-value targets
 * Documentation ideas
  * how system works
  * how to handle keys
  * ...
 * look at changes mailing list/local mirror changes and generate:
  * reports of what changed
  * links to debdiffs
  * static analysis of changes
  * create a weekly role to review the reports?
  * do a debcompare
* Why do this at all?
 * spectrum of potential things we could catch:
  * accidental dropping of patches
  * malicious
  * idea of who uploads what
  * understanding of what's happening in Ubuntu
  * bugs claimed to be fixed are what was fixed
  * maybe fetch title of the bug that is in the email
  * compare-log type report
 * what to look for:
  * main packages
  * who uploaded what package and if it makes sense (show last 5-10 uploaders)
  * diffstat/debdiff doesn't match description
  * security features turned off
  * new policy kit rights
  * compare-bin
  * last 5 uploaders of the package
  * compare-log type report
 * dealing with new u versions

Also see (Roundtable from Friday) for more ideas.


Work Items

This blueprint contains Public information 
Everyone can see this information.