launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> I can write some code that simply reads the token from
> ~/.launchpadlib/credentials/quickly and attempts to use it to add a new
> GPG key if you are in ~ubuntu-core-dev, and so gets a secret key that
> can sign packages that can end up on millions of machines. A very
> tagetted attack like that would hard to prevent, because there is clearly a
> lot of desire. However, as one of the people that could be exploited in
> this manner I am wary of anything that makes it possible.

OK, we can make WRITE_SECURITY_SENSITIVE a time-limited token that must
be reacquired, say, once an hour. Or we can make it a one-shot token
that must be acquired anew every time you want to perform one of these
actions. However, such a system destructively interferes with our plan
for a desktop credential management app.

Let me explain. I'm now working on adding *another* OAuth access level,
GRANT_PERMISSIONS. This access level is only officially available to the
credential management app. The point of GRANT_PERMISSIONS is to make it
possible to create new OAuth tokens without opening the user's web
browser. The credential management app will ask the end-user to grant or
deny access within a native GUI window rather than within the web
browser.

You point out that it's easy for a malicious application to get another
application's OAuth credentials. This is true whether the credential's
access level is WRITE_SECURITY_SENSITIVE or GRANT_PERMISSIONS. (Hiding
the GRANT_PERMISSIONS credential somewhere other than the file system
won't help: in the worst case, a malicious application can impersonate
the Launchpad credential management app over DBus.) If you have
GRANT_PERMISSIONS, you can grant yourself any other level of access,
including WRITE_SECURITY_SENSITIVE.

It's no secret that I think the desktop credential management app,
although superior from a UI standpoint, is insecure. Up to this point
the counter-argument has prevailed that malicious client code on an
Ubuntu desktop is rare, so we shouldn't worry about it. I think this
counter-argument has an additional premise that has just been revealed:
malicious client code on an Ubuntu desktop is rare, *and if it does
exist, the worst it can do is screw up your own system/Launchpad
account*. With GRANT_PERMISSIONS plus the ability to upload GPG keys,
once malicious code gets on an Ubuntu system it can easily infect
thousands of other systems.

The obvious solution is to prohibit GRANT_PERMISSIONS from being used to
grant WRITE_SECURITY_SENSITIVE. This means that WRITE_SECURITY_SENSITIVE
cannot be obtained through the desktop credential management app. Every
time you want WRITE_SECURITY_SENSITIVE, you will have to open the user's
web browser and tell them: 

  "Quickly wants to do a very dangerous thing with your Launchpad
account. Because the thing Quickly wants to do is so dangerous, 1) you
need to make doubly certain that you trust Quickly with your Launchpad
account, 2) you need to authorize Quickly in your web browser because we
can't even trust the Launchpad credential manager in this situation."

Since WRITE_SECURITY_SENSITIVE is either a time-limited or a one-shot
authorization, the end-user will find themselves authorizing in the web
browser every time they want to do something dangerous, plus authorizing
in the Launchpad credential app every time they start using a new app,
plus using the web browser to authorize the Launchpad credential manager
itself.

To summarize, a totally new user will need to do the following to upload
a GPG key to Launchpad:

1. Authorize the Launchpad credential manager using the web browser.
2. Authorize Quickly for WRITE_PUBLIC using the credential manager.
3. Authorize Quickly for WRITE_SECURITY_SENSITIVE using the web browser.
4. Upload the SSH key.

Or, if WRITE_SECURITY_SENSITIVE is time-limited rather than one-shot,
you could implement this:

1. Authorize Quickly for WRITE_SECURITY_SENSITIVE using the web browser.
2. Upload the SSH key before the credential expires.

(In the second case, once the credential expires, the end-user will
completely lose the ability to use Quickly. Next time the end-user wants
to use Quickly, they will need to once again authorize Quickly for
WRITE_SECURITY_SENSITIVE, or else authorize the Launchpad credential
manager and then use the credential manager to authorize Quickly for
WRITE_PUBLIC .)

Is this acceptable? Is there a better solution?

Leonard

Attachment: signature.asc
Description: This is a digitally signed message part