Ubuntu Still Trying To Lock Down Third-Party Debs
On Monday afternoon in Oakland was a session entitled Secure distribution of third-party .debs. This session was described as, "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."
This matter isn't new but has been visited a few times now over recent Ubuntu development cycles but with no solution materializing. Developers are trying to decide how to treat .deb packages that are found on the Internet and not within the Ubuntu/Debian archive, Ubuntu developers want to promote pushing software through the Ubuntu Software Center, and other measures to safeguard Ubuntu/Debian packages.
The notes from yesterday's third-party Deb discussion can be found here. The notes are also embedded below for those without Ubuntu Single Sign-On access.
= 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?
15 Comments
