Secure distribution of third-party .debs

This spec has lived through two UDSes

= UDS-Q Session notes =
 New repos on user system?
  - ideally only for a subset of packages
 What to do with .debs that are just found off the internet
  - sources are many (download links, checkinstall things)
  - man in the middle attacks are plausible, especially if you don't get via https
Some stuff has disappeared from partner (eg Opera)
 - we want them to go to developer.ubuntu.com these days (show up in software center)
 - some partners don't want canonical to distribute their software
 -
Why aren't some third parties using developer.ubuntu.com now?
 - Third party needs to build packages for more than Ubuntu (Red Hat / Debian / etc)...simpler to just have Jenkins build the Ubuntu packages and put them alongside the same web server
What sort of tools can we do to help this?
 - Being able to anotate that a particular archive can only install certain packages (eg this repo can only install package named googletalk)
   - protects from accidents, but not malicious packages
 - Software center does have some automated analyses of packages now (and complains about terrible Adobe packages properly)
 - dpkg-maintscript-helper now has debhelper support
  - Are there any other things we're doing properly in maint scripts that aren't in debhelper?
 - Create a metadata format about a repository
   - GPG signature
   - repository name/url/who runs it
   - present it differently in UI?
   - do this instead of third parties shipping .debs to users that add repos (do they do this in maintainer scripts or with just files?)
    - previous discussion on how to add a repo with file-format: https://wiki.ubuntu.com/ThirdPartyApt (need extension for icon/description)
 - pkgme is the solution to a lot of third parties ending up with .debs but no .dscs, so we can then upload these (mostly-binary) source packages to myapps
   - installs stuff into /opt and so on
   - What about things that _have_ to go out of /opt?
     - .desktop files
     - icons
     - links in the path?
    - These sorts of exceptions are defined by the tech board
      - The static analysis tool would need to recognize these file types and such, but feeding back into this process (eg defining a new white-listable outside of /opt thing) would require a long process.

Do we have a lintian profile for 3rd party packages?
 - apt-daemon has lintian as an optional feature
Having static tool to gather data before making a decision about what to do?
Old:

= UDS-P Session notes =
Care has been taken over the years to ensure that clicking a link to an executable on a website doesn't cause untrusted code to be run, and that all package downloads from the Ubuntu archive and from PPAs can be done securely. But lots of community and third-party documentation directs users to download unsigned .debs from websites and install them, and software center facilitates this. We need to examine the security around third-party packages.
- examples of affected packages include google-chrome, gtalk, skype, ksplice*, and dropbox*, most of which are available over unsigned http
- all of these packages are installed as root, with nothing preventing arbitrary code from running in the maintainer script, even if the package is isolated with arkose after the fact
- some of them can't be isolated at all (e.g., browser plugins)
- some of them even add keys to the apt keyring as part of their normal install process
- these packages aren't going away / moving to launchpad, so we need to make recommendations for what we would like to see third parties doing instead
- strawman: SC should not allow any maintainer scripts to be run for any package that's being installed from a .deb instead of a configured, secure apt source
All of the packages listed initially were more or less standalone applications. Dropbox and Ksplice both integrate much more tightly into the system, which I think makes them good standins for 3rd-party packages in general. ~broder
Note that we actually break third party packages that add repositories on upgrade. If you install Dropbox (and the package install script adds the dropbox repository), update-manager will disable that third party repository when you release upgrade, freezing your version of Dropbox. This is arguably less secure, since the user is locked out from third-party updates. ~Scott Ritchie
That's not true - there's a poorly documented config file you can drop into /etc/update-manager that will do the obvious s/natty/oneiric/g (or similar) on 3rd party repos. Ksplice, for instance, ships that file.
That is super undocumented. Heck, even Google has this super long complicated script to check if they have been disabled via upgrade and to reenable themselves (for Chrome anyway)
*"0install" has a good security model and features that are also friendly to the user, something similar could be applied to ubuntu.
http://0install.net/features.html
http://0install.net/injector-security.html
Scope:
- Measuring the problem
  - Use popcon to measure how many third-party .debs people have installed
    - ~10% have Dropbox installed
    - that wouldn't distinguish between, for example, archive and non-archive versions of Skype
- Reducing supply of third-party .debs
  - Promoting and making it easier to use MyApps and the ARB
    - make it possible to use (free at least) MyApps applications from the command line
      - talk to the Consumer Applications server team about whether they could do this [slangasek]
    - trust third-party repositories within MyApps [achuni]
  - Getting ISVs that are in USC to link to USC (apturl)
    - Provide buttons, tutorial on how to link to your package in USC [mpt]
    - Contact Google, Dropbox etc to ask what it would take for them to use MyApps [jpugh]
  - Skype is in USC, but still offers a standalone .deb for download on its site
- Increasing security of installation of third-party .debs
  - Encouraging distribution of .debs over HTTPS rather than HTTP [jpugh]
    - <kees> fwiw, I'm still driving the HTTPS vs HTTP thing inside google.
  - Can we use extended attributes to track source URL of a file?
    - compare http://support.apple.com/kb/HT3662
      - investigate this [broder]
  - Making it easier to set up a third-party repository
    - Some .debs set up a third-party repository in their install script (e.g. Chrome)
    - e.g. MIT has Debathena <http://debathena.mit.edu/>, a 3rd-party repository for site-wide settings etc
      - they're not interested in wider distribution, so MyApps wouldn't make sense
    - evaluation presentation of URL handler for a third-party repository [mpt]
  - rating third-party repositories
  - discouraging/preventing maintainer scripts for third-party .debs
    - follow up with Colin about this [slangasek]
    - Chrome has a maintainer script specifically to set up the third-party repository
  - Better isolating packages not delivered via trusted apt methods
    - evaluate possible use of arkos to contain third-party packages [stgraber]
- Discouraging users from installing third-party .debs
  - Restrict what third-party .debs can do
    - Confine them to /opt (too early to do that, the tools aren't ready)
    - block maintainer scripts? too much damage?
      - block maintainer scripts that are not debhelper-autogenerated [slangasek]
      - Mythbuntu mirrors their own PPA, which contains .debs with maintainer scripts setting up DBs
  - Make third-party .debs look scarier in USC
  - Encourage people to install any version in an official archive instead [mpt]
    - https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=view&target=software-item-screen-standalone.png
      - say "{Ubuntu/Canonical} has a *trusted* version" [mpt]
- Handling third-party .debs better when upgrading your OS version
  - When upgrade is finished, try re-enabling third-party repositories [mvo]
  - Better explain whether third-party repositories are providing updates for the OS you've upgraded to [mpt]

== Ubuntu 12.04 work items list ==
[slangasek] talk to the consumer software server team about support for commandline MyApps installation
[achuni] trust third-party repositories within MyApps
[mpt] Design buttons, tutorial on how to link to your package in USC: DONE
[jpugh] Contact Google, Dropbox etc to ask what it would take for them to use MyApps: POSTPONED
[jpugh] Encourage distribution of .debs over HTTPS rather than HTTP: DONE
[broder] Investigate using extended attributes to track source URL of a file (e.g. downloaded .deb)
[mpt] evaluate presentation of an URL handler for a third-party repository <http://i.imgur.com/UKFDZ.png>: DONE
turn on support for aptrepository handler (apt+https://): DROPPED
[slangasek] follow up with Colin about discouraging/preventing maintainer scripts for third-party .debs, and update this work item accordingly
[stgraber] evaluate possible use of arkos to contain third-party packages: POSTPONED
[slangasek] block maintainer scripts that are not debhelper-autogenerated
[mpt] Encourage people to install any version in an official archive <https://wiki.ubuntu.com/SoftwareCenter#encouraging-archived-version>: DONE
[mvo] When upgrade is finished, try re-enabling third-party repositories
[mpt] Better explain whether third-party repositories are providing updates for the OS you've upgraded to <https://wiki.ubuntu.com/ReleaseUpgrades#ready>: DONE
12/12/2011 - It looks like there's already a draft spec for a filesystem xattr to track the origin URL of a file (http://www.freedesktop.org/wiki/CommonExtendedAttributes - user.xdg.origin.url) and an open bug against Firefox to support it (https://bugzilla.mozilla.org/show_bug.cgi?id=665531) ~broder
01/30/2012 - Per discussion with slangasek, this didn't end up getting approved for "p", so moving it to "q" release for consideration, and unlinking it from the p topic, so it stops getting tracked.

Work items:
[vorlon] talk to the consumer software server team about support for commandline MyApps installation: TODO
[elachuni] trust third-party repositories within MyApps: TODO
[jpugh] Contact Google, Dropbox etc to ask what it would take for them to use MyApps: DONE
[mvo] When upgrade is finished, try re-enabling third-party repositories: TODO
[broder] Figure out if we can punt the make-google-earth package from the archive (in favor of Google's official .debs): TODO
[stgraber] Write wrapper script that does static analysis of a .deb file, checking for known issues in the install paths, file modes and content of the maintainer scripts: TODO
[stgraber] Look at previous work on implementing a repository definition file, extend to support description (with translation), icon and list of allowed binary packages (setting up apt pinning): TODO
[stgraber] Once format is agreed on, get support for it in the existing tools (apt-add-repository, software-center, file handler): TODO