ThirdPartyApt

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/apt-third-party

• Created: JerryHaltom

Introduction

ThirdPartyApt defines a file format that ISVs can publish on their web sites and distribute to users to download their software.

Rationale

Third parties should be able to distribute programs for installation on Ubuntu or other Apt based distros (especially Ubuntu). They should be provided tools to make installation, integration and maintenance of their programs easy. We have existing infrastructure to provide to them, but need to do so in a consistent way while providing an easy to use interface.

Scope and Use Cases

The main use case is simple. A user should be able to be provided a link to click on by a third party ISV which will start the installation of that ISVs software. The ISV may provide this link on a Download page, or after an accepted payment transaction as been processed.

The user should click on such a link, and be provided an explanation of that they are about to trust the third party to install software onto their system. The installed software should track updates from the ISV automatically and integrate into the existing infrastructure.

Design

We are missing a link between the act of clicking on a link on the web and the package itself being installed. Here I seek to provide a possible way.

A file format should be created that encapsulates a number of pieces of information necessary for installing a remote application or set of applications. This file format is called a ".apt" file.

The APT file is formatted with standard DPKG stanzas. Each stanza contains a GPG key, repository URL and filters describing what type of platform this URL is suitable for. Consider the example stanza:

Name: Figlet
Architecture: i386
Distribution: Ubuntu
Codename: breezy
Release: 5.10
Archive:
 http://us.archive.ubuntu.com/ubuntu breezy universe
PublicKey:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v1.4.0 (GNU/Linux)
 .
 mQGiBEFEnz8RBAC7LstGsKD7McXZgd58oN68KquARLBl6rjA2vdhwl77KkPPOr3O
 <etc>
 =C9XB
 -----END PGP PUBLIC KEY BLOCK-----
Install: figlet

Name species a friendly name to call the package. This appears in the UI.

The next 4 tags, Architecture, Distribution, Codename and Release specify the distribution that this stanza applies to. Any can be omitted. Only the filters that are present are applied. If you want the stanza applied to all Archs, remove Architecture. Most of these are probed from lsb_release. This will allow one .apt file to be generated for multiple distributions or versions thereof.

Archive lists the APT archives to add to the sources.list file.

PublicKey contains a GPG public key to add to apt-key to trust for package installation.

Install specifies which package or packages to install from the archive, seperated by spaces.

Method

A program is provided to handle the .apt file type. When this program launches a .apt file, it parses all the stanzas and determines which applies to the current environment. It then walks the user through a few simple questions asking if they are sure they want to trust the PublicKey to install software onto their system. After the user has confirmed all the steps, the public key is added to apt-key and the packages specified by Install are installed.

Implementation: ["GAptI"]

Security

The obvious security considerations do not go away. Yes, a malicious software provider could provide a .apt file which adds a trusted key and repository to the user's apt-key and sources.list. Is this a problem? Users want to install third party software. Providers want to provide it. Yes, this software may make system-wide configuration changes. Yes it may REQUIRE root to run. The best we can do is provide a proper interface by which the user can manage these things, and make him as aware as possible of the consequences. Forcing third parties to come up with their own packaging method isn't it, and that's what they do now. Users have to drop to the command line and run a .bin, or a .run file, or whatever the provider provides. These packages don't integrate into the system. They can break things, install software in the wrong location, overwrite existing files. But people use them, now.

In that vein, when the "are you sure" dialog opens, if the key is not currently trusted, the window should very explicitly state that they are about to trust the provider of the software to provide updates. I'd suggest the OK button is disabled for the first 5 seconds, forcing the user to actually wait, perhaps reading the message.

Related Pages

• ["GAptI"]

• ThirdPartyPackages

• https://wiki.ubuntu.com/aptgetinstallprotocol

Comments

• MatthewPaulThomas: This seems to be a reinvention of [http://autopackage.org/ AutoPackage], but with not so much portability.

• ArwynHainsworth: You mean [http://autopackage.org/ AutoPackage] is a reinvention dpkg/apt-get, right?

• ArwynHainsworth: The proposed idea as it stands has a HUGE security flaw. If the program that handles .apt files can add any generic repository is sees in the file, what is to stop l33tHax0rs & co. from creating a repository with a deb of a slightly patched kernel (or any other core system deb)? He doesn't even have to get the user to install it directly, all he has to do is get the user to add his repository (with a completely harmless and useful deb) and wait for the user to update. Solution: 1) Remove the Archive: tag completely. or 2) Only allow repositories to be added if they are on a whitelist.

• Killerkiwi: Id vote for only allowing the install if the list repo is in the sources.list else just display an error, "You need to enable the following repo to install 'foo'"

• JohnMccabeDansted: If you want to run 3rd party software you pretty much have to trust the third party, unless you constrain the software using something like Plash or SysTrace. I guess a whitelist of third parties might be useful, or a whitelist of public keys owned by people trusted to approve new repositories.

• JerryHaltom: The last comment explains it. There is *no* answer to installing software on a user's PC that does not leave open the possibility for that software to be untrusted. None. It is currently an unsolvable problem. The entire goal is to install software that isn't already in Ubuntu, and thus it can't be considered trusted by Ubuntu. Either you make installing untrusted software impossible, or you ignore the problem. What this seeks to do however is provide an easier way, to do something people will do already.

• TristanWibberley: There needs to be several things happen, and in a particular order, I think:

  1. *All* daemons in Ubuntu repositories or scripts/programs that will configure themselves to be run from a daemon, and all suid/sgid programs should be configured off by default. Programs that are supposed to be run with sudo should have to configure sudo to allow them so they are off by default too.

  2. Do what Killerkiwi said.

  3. Repositories should be configurable with a metadata-trust rating, whereby more trusted metadata in one repository will mark changes in other repositories - this prevents dependencies/conflicts/etc from stopping security updates.
  4. Users should be able to have their own repositories and install roots so they don't have to screw with the main system repos.
  5. Pre/postinstall scripts should be run in a strictly controlled environment where suid/sgid bits and daemons cannot be configured.

• JerryHaltom: I am not trying to solve this problem. It is unsolvable, as stated earlier.

  1. You can't control that. Point 4 makes it impossible.
  2. Killerkiwi said to only allow repositories that are already listed. That completely defeates the point of the specification, which is to ADD NEW REPOSITORIES!
  3. Too complicated and impossible to enforce because of point 4.
  4. I seek to provide a method to distribute software that may require root... such as, for example: VMware. Given that, the install must run as root and must be able to add kernel modules. Given that, anything attempt to enforce security is useless, as it can be bypassed.
  5. Again, point number 4.

• TristanWibberley:

  1. Is easily possible since the Ubuntu repositories are controlled by the Ubuntu devs, and it is required to provide a predictable security boundary for those that will refuse to allow new repositories, but will want to allow packages in existing repositories to be installed via links in a web browser. IMHO a feature like this should not be available in Ubuntu without that first security feature.

  2. The second thing you should do is what Killerkiwi said: "only allowing the install if the list repo is in the sources.list else just display an error", but then once that is done and the implications understood it would be safe to move on

  3. Is possible to enforce for all repos where the repo administrator can be trusted not to provide trojans or to mess with the dpkg status file - but can't be enforced against malicious repository admins.

  4. and,
  5. are not needed to acheive what both you and I want, but they are further steps on the development of this feature.
  I think we disagree on what is an acceptably high barrier to the inadvertant introduction of security holes and an acceptably low barrier to the removal of security holes.

• JerryHaltom: I'm not sure if you're reading my proposal or somebody elses. You keep going on about Ubuntu repositories. You keep going on about not allowing this unless the repository is in sources.list. My proposal is contrary to those two. My proposal is about *automatically* adding lines to sources.list, because that is the entire point, installing software which is not in Ubuntu. My proposal is to avoid having users edit some silly text file on their own. If you don't like the idea of allowing users to install third party software on Ubuntu without hand editing some text file, then you need to present some sort of argument against that, not all this other stuff.

• TristanWibberley: The installation of third party software will normally require that dependencies be met from within the Ubuntu repositories, so management of Ubuntu packages needs to be a part of it. And since installing third party software under the direction of a resource at an URL will have to work on a third party repository that has already been added to sources.list, mere installation of Ubuntu packages from existing repositories is a proper subset of this feature. So I don't think it is either orthogonal, nor extraneous.

  I do like the idea of installing third party software on Ubuntu without hand editing some text files and I am not trying to put the stoppers on it - I had even implemented the basic (insecure) version in less than 20 lines of bash when I suggested it on the lists (just after somebody proposed mere installation from existing sources via a new url scheme, a couple of weeks ago). I am trying to ensure that Ubuntu doesn't earn a reputation for being as insecure as Windows is. This feature is more complicated to get right than it appears.

• JerryHaltom: Sure, but those dependencies will be met from the existing Ubuntu repositories, as you said. ISVs would distribute .apt files which provided specific support for specific Ubuntu releases. For instance, an ISV would provide a .apt file which would expose breezy software to a breezy user, compiled against breezy. Since ubuntu has defined and supported releases, this is feasible, and quite clean. The last point about security, in my honest opinion, is like trying to add 2+3 and get 4. It just doesn't work. You cannot both provide support for users to install software which requires kernel level access (VMware) and yet restrict it to make it safe. I may not be imagintive enough, or something. There are only a few solutions to this problem which I can see: 1) you either restrict users to installing only approved software, which guarentees it won't have an impact 2) you only allow users to install "certain" third party software that doesn't require root access 3) You come up with a system which sets up a virtual machine for every software install. 1. seems like limiting the user's choices, and is currently circumventable and currently circumvented (VMware provides it's own installer) 2. requires a central point by which all ISVs must vet their software, which is practically identical to 1)... either you keep up with all software and updates, or they'll just use their own systems anyways 3) impossible to do in any meaningful way, now and for the forseeable future. In light of all of that, the only remaining way is to provide the user a method to do what they want to do, ensuring that at least the ISV is using an approved system to deliver the software, that we can vet. That system is apt and dpkg. It allows the user to use his existing tools to manage his installs and updates. apt itself is cross paltform and can deliver even RPMs, which makes it even more compelling. Defining a .apt standard file format could be used to deliver software to many different distributions. Yes, it doesn't go as far as autopackage, making the vendors job of testing against distros certainly time consuming. Implementation of the program in charge of this: GAptI would need to have a lot of community agreement as to the wording of the message. The current GAptI implementation I have written does what I think is a reasonable job: It explains to the user what is going on, and forces him to wait 15 seconds before he can hit Install. This in my opinion is a best case option. Certainly I am not against considering furthur ways to bullet proof this process. The job of establishing a relationship with a third party repository is one which the user needs to be walked thru with the upmost care. The entire proposal, however, does rest on the approval of providing a GUI method by which a user can trust a currently untrusted third party repository.