Allow to install system wide license keys

[Sebastian Heinlein]

There is the need to allow sharing software license key by all users on the system. So they need to be dropped to an accessible location on the system. This bug tracks the discussion and progress of this effort.

From a security point of view we allow a desktop user to "randomly" drop files on the system. So we should try to define the dropping area and the content of the file as tight as possible.

Open issues:
* Can we assume that we can patch or force the shipped software in /opt to use a common place defined by our policy (problem with proprietary software)?
* If the above question is yes: Can we store the licenses in a central repository e.g. /var/licenses/pkgname.key? Or should we store them in the corresponding /opt/pkgname dir?
* If the first question is no: Can we still assume that the key has to be stored in the /opt/pkgname dir? E.g. Does a "special" customer insist on uppercase naming which is not allowed as a package name /opt/AcrobatReader?
* Can we sign the key by Launchpad to make sure to only drop a file which can be sure of to be license key? The signature check needs to be done by aptdaemon
* We need a trusted way to transfer the location of the key to aptdaemon - current solution would be to store the key path in a package control field (XB-LicenseKeyPath). But we could also append this information to a signed license key, see question above.

[Sebastian Heinlein (glatzor)]

Or a more basic question: Why don't you ship licenses in packages? It is just a static file.

[Michael Nelson (michael.nelson)]

On Thu, Aug 25, 2011 at 9:47 PM, Sebastian Heinlein
<email address hidden> wrote:
> Or a more basic question: Why don't you ship licenses in packages? It is
> just a static file.

Yep - I'd be keen to hear the discussion around that too. I was last
night thinking about a similar point from the other direction: Don't
we also want to allow people to install a publically available deb,
and then purchase a license key to unlock functionality?

Thanks for summarising the current situation Sebastian. And just to be
clear for other readers, what's currently required on the server is a
relative path for the license key - relative to the installed binary
executable (ie. if the app is in /opt/mypkg/runme.bin, then the
license key path specifies any path within /opt/mypkg/ - that was done
with bug 833053).

[Anthony Lenton (elachuni)]

Copy+pasting from the thread where packaged keys was dicussed:

(...)
The main option on this thread seems to be to serve the key from a
 package vs. pulling it in some other way that involves an API.

Packaged keys have several downsides. If we serve them from a per-user
 PPA, it would involve a buildtime for each key package, even though
 the package itself is trivial, so there would be a considerable delay
 between purchasing the app and being able to download the key for it.

If on the other hand we serve the key packages from sca it would
 involve setting up a basic repository layout on our server and
 generating (binary) debs on the fly. Generating and taking care of
 the server certificates, getting them trusted would also be an issue,
 as well as restricting access to the deb file during installation so
 that only the rightful owner can access it.

Lastly, USC would need to enable more than one source per purchase, and
 download more than one package, so it would still need changes on the
 client.

The alternative would be to provide an authenticated api call that
 provides the key. There was a downside with this too: if the key is
 pulled in as part of a post-install hook, it would be running within a
 different environment that would have root privileges but possibly not
 the right network setup or user credentials to get at the key.

There is a way around this, and that is to have USC get the key as part
 of the purchase process (together with the private deb line, or in a
 separate api call). It has all the right network setup and
 credentials at that point, and it can put it into a standard location
 for the application to check.

Which location to use for the key was another question. Ideally it
 would be somewhere within the user's home directory, but the downside
 of that is that users might tamper with their own key file and delete
 it or break it unintentionally. A free advantage of USC setting up
 the keys is that there could be a menu option like the current
 "Reinstall previous purchases..." that would refetch license keys for
 you. And it could do this without needing to redownload and
 install the app (another advantage over post-install hooks). Looking
 at xdg mvo has recommended ~/.config/software-center/license-keys/ as
 the standard location for storing the keys. Within that directory we
 could place one file per application.

(...)

[Michael Nelson (michael.nelson)]

Thanks for including the discussion Anthony. The one question I think is still unanswered though (and unsupported by our current implementation) is:

Don't we also want to allow people to install a publically available deb, and then purchase a license key to unlock functionality?

But maybe that's a future plan...

[Sebastian Heinlein (glatzor)]

Thanks for the summary. Well thought. So packages don't seem to be a good solution. The technical implementation depends on a social component: Can you enforce the location of the key/policy to all vendors? If there is perhaps a proprietary software which insists on a custom location we need to transfer the path somehow, currently the preferred way would be a package record/control field. Otherwise we could just simple hard code the path. It would make sense to store the key outside of /opt/pkgname to avoid people "uninstalling" software by "rm -rf" and deleting the key. A possible path could be /var/lib/licenses/pkgname.

Is there a way to sign the license keys by Launchpad?

[Michael Vogt (mvo)]

There is currently a disconnect between the way the server implements this feature (via a license_key and license_key_path json return value) and what aptdaemon expects.

Aptdaemon wants to have the license key path as part of the pacakge record. This means that it needs to be added via "XB-LicenseKeyPath" in debian/control. This ensures that we can trust the location and thats its impossilbe to abuse this call for attacking the system.

[Michael Nelson (michael.nelson)]

@mvo: That's fine - there is nothing stopping the packager/reviewer from ensuring that the license_key_path is part of the package - as we don't yet have pkgme doing the auto-packaging. Based on comment 5 above, I'd recommend that the client checks the package for the XB-LicenseKeyPath, and if it doesn't exist, uses one of the sensible defaults mentioned there.

 For the future automated scenario, we need to ensure pkgme includes the license_key_path too.

[Sebastian Heinlein (glatzor)]

What about the trust level of the key content? Is it possible to sign the key by Launchpad automatically? I have good a bad feeling dropping unknown files to the system. This is a possible security attack vector.

[Anthony Lenton (elachuni)]

Hi Sebastian,

I don't really know what would be needed to get LP to sign the keys. They don't currently get stored on LP at all.
Currently the key is being sent over https, and the latest httplib2 does verify the server certificate, so we're pretty sure it does come from the sofware-center-agent server, would this cover the vector you're concerned about?

[Sebastian Heinlein (glatzor)]

Sorry, I don't know the infrastructure on the server side. I was just guessing about the key location.

Using ssl would indeed help. But aptdaemon has to be sure that the key comes from the correct server. The aptdaemon InstallLicenseKey method can be invoked by every application - not only by s-c-agent. So the downloading would have to be done by aptdaemon.

So we could validate the download url by a regular expression and add ssl verification.

The url requires a password? OAuth is used?

[Anthony Lenton (elachuni)]

Discussed briefly on irc.

One way to make this call secure would be to make the AddLicenseKey call:
AddLicenseKey(packagename, token, server)

aptdaemon could then contact the (trusted) server, authenticate with the provided token and retrieve the license key itself.

It would need to receive the OAuth token as an argument because it doesn't have access to the session bus to request the token itself.

The server argument would need to be restricted to "production" or "staging", so that you can't ask aptdaemon to contact just any server.

It might be best to package the sca client library separately for aptdaemon to use.

Optionally, aptdaemon could read an environment variable to check which server it should contact, and make the call receive only packagename+token.

It could even reuse SOFTWARE_CENTER_BUY_HOST, the same env var software-center uses, with the same restrictions: it should only be allowed to refer to the trusted staging or production server.

Alternatively to the packagename, the call could receive a subscription (numeric) id, and fetching that from the sca api will provide the package name together with the license key.

[Michael Vogt (mvo)]

I'm sorry that this seems to go on forever, but I finally picked this up again and added support for piston-mini-client/scagent direclty in the aptdaemon. This means that after the install of the purchase app it needs to run a "subscriptions_for_me" call (or subscriptions_by_id) and wait for the server to return the result. The code is now mostly there in aptdaemon, I need to refactor some more to make the tests better.

Software-center needs a little bit of tweaking too, in the purchaseview it needs to grab the token data it gets from the server via the console.log() call and pass that json_token to the aptdaemon client call.

[Michael Vogt (mvo)]

The code for aptdaemon is now in trunk and 12.04. In 12.04 we need a additional helper package "softtware-center-aptdaemon-plugins" that is waiting in NEW currently. Then there is lp:~mvo/software-center/system-wide-license-key-fixes that needs merging once the plugin package is available in 12.04.