Security Catch-all

NOTE: Adjusted to jdstrand as the assignee since Kees left and the reports are not correct.

Work items:
[kees] upstream remaining 2 gcc testsuite cleanups: POSTPONED
[kees] find and fix any newly created testsuite failures in gcc 4.6: POSTPONED
[kees] create a set of docs for how to run the gcc testsuites and get good results out of them for fixing future issues: POSTPONED
[jdstrand] internal self-analysis of LTS releases: POSTPONED
[mdeslaur] fix openssl reboot notification for desktop: DONE
[jdstrand] Send and announcement saying that we are no longer sending security announcement to bugtraq and full-disclosure: DONE
[broder] write a script to report -backports packages that need an update due to -security: POSTPONED
[mvo] add dialog to PPA to show description and ask for confirmation (cli only currently): POSTPONED
[kees] rest API that exports json (eg lucid/main/mysql and this dumps CVEs: POSTPONED
[mdeslaur] followup with mvo to update dash and software center (filter it out): POSTPONED
[mvo] to write tool to report security status of installed packages: POSTPONED
[jdstrand] bring idea of 'check orig tarball' via watch files up to foundations: DONE
[jdstrand] update vm-new to use vmvga on natty and higher, for unity-2d support: DONE
[mdeslaur] look at vm-new and vm-iso to use preseeding and get rid of vmbuilder (live-build may also be a possibility): DONE
[mdeslaur] in umt, move check-* before sign: DONE
[kees] add a compare-log for ppa builds to umt: POSTPONED
[mdeslaur] general improvements to compare-bin (and its dependencies). For example, look at file difference not unified diff: POSTPONED
[mdeslaur] add a warning to umt check when devel and vcs-bzr tag is found: DONE
[jdstrand] cleanup/commit vm-update to tree: DONE
[kees] write a LP-deb fetching script to download specific debs of a release like sppa_copy_repo: POSTPONED
[kees] implement the packaging logic for qrt: POSTPONED
[jdstrand] investigate vm-qrt script (make-tarball, vm-scp and qrt integration): DONE
[mdeslaur] cve_need_retire -u: DONE
[kees] write python module for CVEs: POSTPONED

Possible:
[mdeslaur] investigate getting rulesets for mod_security automatically, and possibly providing those if they don't exist
[mdeslaur] investigate if mod_security meets MIR requirements
[mdeslaur] talk to server team about championing mod_security, and getting it in the server seeds
[sbeattie] contact cr3 about frameworks in use and how they deal with private data
[kees] ask cjwatson about disabling password auth in openssh-- if there is any more we can do
[mdeslaur] discuss with server team the possibility of disabling password auth with cloud via orchestra
[sbeattie] have ability to choose what kinds of tests to run (functional, security, regressions)
[kees] have ability to disable network tests
[mdeslaur] document how to audit policykit (relationships, where to look, how to examine one application, how to examine the archive)

Going forward, in general:
* when doing security updates, always look for test suite, and if it isn't enabled, file a bug in the devel release. Investigate adding said testsuite into QRT using new functions
* invite gnome-keyring maintainer to UDS

Some of the above also came from the security team private meeting on Monday.

From etherpad (http://summit.ubuntu.com/uds-o/meeting/security-o-catch-all/):
* gcc testsuite updates for hardening updates to not interfere with testsuite. Overview:
  * fix clear upstream bugs [done]
  * bugs that are upstream but upstream needs to be convinced
  * upstream bugs upstream is not interested in (eg, turn off stack-protector for this test)
  [kees] upstream remaining 2 testsuite cleanups
  [kees] find and fix any newly created testsuite failures in gcc 4.6
  [kees] create a set of docs for how to run the testsuites and get good results out of them for fixing future issues
 * mod_security
  * maintenance burden
   * we don't want to ship rulesets because we want people to use up to date ones
   * they now have a public repo
  * suitable for main?
   * has rulesets which need to be updated regularly
   * rulesets might require a new engine (provided by our package)
  * other items?
  * this does meet PCI requirements
  [ACTION] investigate getting rulesets automatically, and possibly providing those if they don't exist
  [ACTION] investigate if it meets MIR requirements
  [ACTION] talk to server team about championing this, and getting it in the server seeds
* audit frequently updated packages to make sure the testsuites are enabled
 - checks in build logs that are package specific (ie, 'make check' is still in there) -- can do this in the new archive checks
 - new catch-all test results database
 [ACTION] contact cr3 about frameworks in use and how they deal with private data
Queston: can we hook into coverity?
 - static tools are a bit of a future goal here, since we can hardly deal with format strings issues in the archive.
 - Some projects use them and clean up the warnings/mark the spurious ones
Question: is there a way to limit openssh logins? What exists
 - fail2ban
 - ufw
 - no password authentication
 Should Ubuntu being doing more here?
 [ACTION] ask cjwatson about this
 [ACTION] discuss with server team the possibility of disabling password auth with cloud via orchestra
QRT:
- [ACTION] have ability to choose what kinds of tests to run (functional, security, regressions)
- [ACTION] have ability to disable network tests
- [ACTION] when doing security updates, always look for test suite, and if it isn't enabled, file a bug in the devel release. Investigate adding said testsuite into QRT using new functions

Roundtable day 2 (http://summit.ubuntu.com/uds-o/meeting/security-o-tue/):
From our weekly meeting:
 * is a whitepaper worthwhile?
  * what is the purpose? to discuss the exposure for a given release
  * provides self-analysis
  * first 6 months of hardy and/or lucid (LTS)
  * reclassify as CVSS? probably not-- to otime-consuming
  * report can discuss what our proactive measures protect against
  * is the time spent on it worth it?
  * postmortem style
   * where we can do better
   * regression updates
  * bottom line: self-analysis is useful
   * start internally with LTS releases (Lucid first)
   * what was protected (mitigations, etc)
   * regresson rate
   * what regressed
   * look at high
   * couple to really look at
 * Severity in USNs
  * why? to rate limit updates
  * we like to update as soon as possible and let the user/organizaiton decide
  * good mirror/proxy software could help organizations with this. ie, they mirror and Ubuntu has software that says 'you can mirror this update now, but not this one'
 * software centre suggestions: check if any open cves for that release that are medium or higher and not display them. invite mvo if not already in another software center session. also ppa description
  * reboot notification (openssl)
   * [ACTION] mdeslaur will fix for desktop
   * no information on what is triggering the reboot notification
    * Is there a logfile? can we create one?
    * there might be multiple packages that trigger a reboot notification
 * dbus service and polkit permissions discussion
 * md5 out of infrastructure (ScottK). what applications are using only md5 in a security context?
 * still publish announcements to full-disclosure and bugtraq?
   - Send and announcement saying that we are stoping sending security publications and explaining how to keep getting them from out mailing list.

Roundtable day 3 (http://summit.ubuntu.com/uds-o/meeting/security-o-wed/):
Old business
* USNs to bugtraq and full-disclosure
 - micahg sent one
 - [ACTION] jdstrand: who will send email saying we've stopped
* review of yesterday's sessions
 - UEFI
 - screensaver
  - gnome3 doesn't have hacks. likely port the old to gtk3. likely moving forward will integrate this more tightly with gnome-shell (upstream) and compiz (Ubuntu)
  - Debian delta: analysis of methods of creating the debdiffs in LP
   - we sign the compressed contents which affects how we analyze changes of contents
 - took ownership of TPM chips for using it for key material store
 - update policies for clients tied to network services
  - how do we test radically updated software for UbuntuOne, Landscape, etc
  - mix mentality of firefox updates (lots of embedded code), with /opt and SRU updates pulled into /opt
* updates

New business
* gnome-keyring (see https://lists.ubuntu.com/archives/ubuntu-hardened/2011-April/000544.html )
 - gnome-keyring should be able to use smartcards (and tpm)
 - does it do challenge/response at all?
 - gain a bit in the offline attack scenario
 - it has a pkcs11 implementation in it
 - could be moved to nss
 - [ACTION] invite gnome-keyring maintainer to UDS
* mvo to visit us tomorrow
 - software centre suggestions: check if any open cves for that release that are medium or higher and not display them. invite mvo if not already in another software center session
 - print PPA description text when adding a PPA to software sources so PPA owners can inform users
* dholbach to visit in security-o-community. Notes from ad-hoc session will be in the etherpad page for the track
* dbus service and polkit permissions discussion
 * dbus/policykit being used to connect to root services is becoming a problem
 * new style:
  - define a service file
  - can specify the user (eg user=root)
  - it receives input (via dbus messages) from unprivileged applications
  - policykit was bolted on to allow for applications to ask policykit for authorizations. This opt in, but people are getting it wrong (don't do checks right, api is too wide, etc)
  - can't map the dbus interface to the policykit policy because the namespace in policykit is application specific and hard-coded
 * how to audit ideas methodologies:
  - if provide a service file, check it for root
  - all the applications that use dbus and run as root
  - look at all the policykit
  - if provide a service file, and runs as root, check if using policykit at all
  - policykitdump?
  - write a tool to examine the system to say where everything is
 - [ACTION] document
  - relationships
  - where to look
  - how to examine one application
  - how to examine the archive
* md5 out of infrastructure (ScottK). what applications are using only md5 in a security context? Seems likely fine for now (nothing security relevant (for package distribution and authentication) is using md5 as sole hash mechanism?
 - md5 has risks. they'll get worse
 - what we learned from sslv2: people complained that they couldn't use this for testing or auditing (eg, openssl can't be used to create a connection to a server to test if it doesn't have sslv2)
 - what can we do to be ready to turn it off (in case we have to)? Ie, be ready for when it totally fals
 - http://valerieaurora.org/hash.html
  - Going forward
   - have a stated policy?
   - make it so hashing algorithm can be swapped out
   - documentation updates (wiki recommendations)
 - what we've done
  - salted sha512
  - combined with sha1 and sha256 in Debian packaging (believed to only use the highest). Dapper still uses md5
  - natty no longer uses md5 in debootstrap
Backports discussion
- it is important to make sure backports gets security updates since it is likely to be used more
- [ACTION] ebroder to write a script based on info available (best approach: run a script to scan the archive to generate a report)
Questions
- dbus services and web applications/browser integration
 - basically talk to our team in the design process. David Barth

Roundtable day 4 (http://summit.ubuntu.com/uds-o/meeting/security-o-thu/):
 * reboot notification (openssl)
  * [ACTION] mdeslaur will fix for desktop
  * no information on what is triggering the reboot notification
   * /usr/share/update-notifier/notify-reboot-required
   * Is there a logfile? yes: /var/run/reboot-required.pkgs
   * there might be multiple packages that trigger a reboot notification
 * Add PPA description dialog to adding PPAs in software sources
    * [ACTION] mvo - add dialog to PPA to show description and ask for confirmation (parse e.g. https://launchpad.net/api/1.0/~mvo/+archive/ppa)

 * in applications dash, it makes suggestions. Is there a way that if software has open medium or higher CVEs then the software center wouldn't
 [ACTION] kees - rest API that exports json (eg lucid/main/mysql and this dumps CVEs
 [ACTION] followup with mvo to update dash and software center (filter it out)
 [ACTION] mvo - to write tool to report security status of installed packages

Roundtable day 5 (http://summit.ubuntu.com/uds-o/meeting/security-o-fri/):
Old
- Updates
- ufw network-manager integration
- kernel SRU cadence
- OEM request to have hardware maintenance for LTS
 - lts-backports kernels plus a bit of the stack (eg X for SandyBridge, etc)
- kernel versions and flavors
 - no new flavors, 2.6.40 probably (provisionally)
 - modules for virtual kernels
- kernel delta review
 - modules for virtual kernels
 - they have few commits for code changes (~170)
New
- dbus/
- yama status - not going upstream right now
 - symlink restrictions should be attempted again (and from there, hardlink)
 - ptrace restrictions should be attempted again
- trying to get seccomp2 stuff up
Questions
- new upstreams
- is this a package that we trust? eg, do we trust gcc or the uploader, the security of the keyring
- is this the source code that we trust? (eg, checksums, coordinating the diff to what is committed upstream). Ultimately we want to be able to verify the integrity of our source packages
 - would be good to think about how to match upstream source commits to what actually ended up in the tree
 - try to see a way to
 - Debian QA scripts for watch files
  - extend the scripts to pull down the upstream tarball and our orig and then diff the two (gets around repacks)
 - file bugs against packages that don't have watch files
 - MIR process should require a watch file
 - extend watch file format to also require getting the checksum/sign
 - encourage upstreams to sign the sums file
 - should be able to 'check original tarball'
 - [jdstrand] bring this to foundations
- make it so Ubuntu specifically
 - sum of the upstream tarball to our tarball
 - we could regenerate a tarball from the tagged check out
 - could identify key packages and look at sum in the release email and compare to what is on the website