launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

Introduction: Can We Do As Well As Ubuntu One?
==============================================

Let's say you boot up your new Maverick system, fire up Rhythmbox, and
decide to buy some music from the Ubuntu One store. What happens?

An application window pops up on top of Rhythmbox, asking you for your
Ubuntu SSO login and password so that you can get access to Ubuntu
One. Being a new user, you don't have an Ubuntu SSO account, so you
get a chance to create one. Once you have an account, you accept the
Ubuntu One T&C, and the application window secretly uses your
authorization to store a token on your computer.

This token allows applications to use Ubuntu One under your name.
It's stored in the GNOME keyring. You never see the token, but it's
there, and usable by other applications.

You buy your music, and then you get to work, writing some notes in
Tomboy. Once you're done, you decide to sync your notes to the cloud
using the Ubuntu One integration features of Tomboy. What happens?

Well, nothing happens. The Ubuntu One token is available to *any*
application that uses Ubuntu One. You authorized Rhythmbox, but Tomboy
can use the token too. Tomboy grabs the token you created from
Rhythmbox from the GNOME keyring and syncs your notes.

The Control Panel, desktopcouch, cloudserver, and every other
application that uses Ubuntu One can grab this token from the GNOME
keyring, without asking you, and access your Ubuntu One account.

Uh-oh! Rhythmbox just crashed while it was playing your music! Now a
dialogue box pops up, asking you if you'd like to report a bug. You
would like to report a bug, so you go through a process that's pretty
similar to the process you went through when you wanted to buy some
music:

A browser window pops up, and you're asked to log in to Launchpad, the
site that hosts the bug reports. You're able to log in using the
Ubuntu SSO account you just created, and then you get a message like
this:

 The application identified as "apport" wants to access Launchpad on
 your behalf. Will you allow "apport" access to your Launchpad account?

 * Yes.
 * No, thanks.

You click "Yes", and Launchpad grants your computer a token that lets
apport use Launchpad on your behalf, without asking you every
time. This token is stored in the GNOME keyring, right next to your
Ubuntu One token.

But of course you don't see the tokens. You just see that apport has
done its job and now there's a Rhythmbox bug in Launchpad with your
name on it. Now you're curious about Launchpad, so you poke around the
site.

You decide that Launchpad is the perfect site to host the little open
source project you're working on, so you start a project and import
your source tree. And you discover there's an application called
Ground Control, which lets you integrate your Launchpad work into your
desktop.

You install Ground Control, start it up, and... your browser opens
again.

 The application identified as "Ground Control" wants to access
 Launchpad on your behalf. Will you allow "Ground Control" access
 to your Launchpad account?

 * Yes.
 * No, thanks.

What happened? How come Tomboy didn't need to ask you for permission
to access your Ubuntu One account, but Ground Control had to ask you
for permission to access your Launchpad account?

This is a question that our users have been asking (albeit not in this
form) since the Launchpad web service was first released. We don't
have a good answer. It turns out there *is* no good answer. It's time
to change this.

Authorize the entire desktop at once
====================================

I have a branch in review that needs some discussion. Here's the merge
proposal:

https://code.edge.launchpad.net/~leonardr/launchpad/rename-grant-permissions

I'm changing the social norms around Launchpad's OAuth token
authorization protocol, *as it's used on the Ubuntu desktop*, to make
it more like the system used by Ubuntu One. Instead of authorizing
individual applications (apport, Ground Control, etc.), the end-user
will authorize the Ubuntu desktop itself. The protocol itself is
unchanged; I'm simply reducing the number of times the end-user has to
go through it.

Robert pulled the brake on my branch because he has legitimate
concerns about my process: I didn't use this list to hash out the
design, and the design has changed radically over the past couple
months. Fair enough. Let me present the stable design in public, tell
you who I've discussed it with, and try to convince you that it's good
on the merits.

The ultimate purpose of this branch is to stop third-party developers
from writing horrible hacks that bypass the OAuth token authorization
protocol. These people are my customers. I can't stop them through
technical means, any more than music companies can stop *their*
customers from sharing songs with each other. But I can get my
customers back on my side, by improving the experience of the
"legitimate" alternative.

I went through a couple iterations of a design in consultation with
these third-party developers, and with the Ubuntu desktop team
responsible for the Ubuntu Single Sign-On desktop app (that's the
thing that lets Rhythmbox and Tomboy connect to Ubuntu One). The
current iteration of the design is based on the fact that the GNOME
Desktop is a unified security context, and that our attempt to
partition OAuth tokens by application is nothing but security theater.

I was shocked when I found this out, but it's true. See here for
details:

http://live.gnome.org/GnomeKeyring/SecurityPhilosophy

My goal is to improve the experience for desktop Ubuntu users by
getting rid of the security theater. When you're giving a website
(maybe Facebook or OMGUbuntu) access to your Launchpad account, our
current design is absolutely *not* security theater, and the current
design will continue to work in that context.

Based on this revelation, I worked with the Ubuntu SSO team to develop
my third, and hopefully final, design. Here's a document that explains
my design in detail. You don't need to read more than the first four
sections, but I would appreciate it if you'd read those four before
continuing.

http://pastebin.ubuntu.com/499131/

On Tuesday I presented this document on a conference call with the
Ubuntu SSO team, Ubuntu technical architect Allison Randal, and Ubuntu
engineering manager Rick Spencer. We specifically talked about the
security implications of this design: what might happen if malware
running on your machine gets access to your desktop-wide Launchpad
credential.

We reached a conclusion that's pretty common-sense: if you have more
to lose, you should be more careful. If you're a big-name Ubuntu or
Launchpad developer, and your computer is compromised by malware, and
the malware takes your Launchpad credentials and does horrible things
like releasing embargoed security bugs, then that's a really really
bad situation. But it doesn't really matter whether the malware does
its dirty work using an OAuth token for "Ubuntu desktop" or an OAuth
token for "Ground Control".

It would also be really bad if malware got access to your Ubuntu One
account, but having different tokens for every app won't help. Because
of the design of X and GNOME, there is absolutely no way to prevent
malware running as you from getting access to your GNOME keyring (or
your home directory, where OAuth tokens were stored in earlier
versions of launchpadlib).

The new design does not lessen security: it does induce a
feeling that something bad might happen because we're taking something
away. Which is exactly what you'd expect from the removal of security
theater.

Side note for the above
-----------------------

There is one use case in which the new system might be less secure
than the old system. In the old system, if malware is running on the
desktop of someone who uses apport to report bugs and has never used
another Launchpad-integrated application or run a Launchpad-integrated
script, that malware will have an effective Launchpad permission of
WRITE_PUBLIC. In the new system, that malware will have an effective
Launchpad permission of DESKTOP_INTEGRATION, which is the same as
WRITE_PRIVATE.

I think it very likely that any privileged Ubuntu or Launchpad
developer who uses the Launchpad web service already has a
WRITE_PRIVATE token lying around their hard drive. It's a pretty
slender reed to hang your hopes on. I'm mentioning it only because
yes, there is a theoretical case in which the new system is less
secure.

The same situation obtains right now with Ubuntu One--any app running
as you on your desktop can read and write all your data, no matter how
private it is. Many, many times have I heard variants on "if there's
malware on your system, you're screwed anyway", from the Ubuntu SSO
developers and from the third-party developers who I'm trying to
convince not to write horrible hacks.

If you really don't trust your apps, you can have GNOME prompt you for
your password before every access to the token.

Things I could go into
======================

This document's plenty long on its own, and it references other
documents that are also long, but there are a few more topics I can go
into more detail on if anyone's interested.

1. The two prior designs I worked out with the Ubuntu SSO team and the
third-party developers were equivalent, in security terms, to this
design. But they were also a lot more annoying to use and would have
required a lot more time to develop.

2. Developers can collude to implement this design without our
consent, by standardizing on a single OAuth consumer key and sharing a
single token across a given desktop. This branch creates a sanctioned,
safe way for developers to do what they can already do without us.

3. There are a couple difference between the way Ubuntu SSO does
things, and the way the Launchpad web service does things. Look into
this, and at first glance, it may look as though Ubuntu SSO *does*
authorize each app individually.

Don't be fooled! Ubuntu SSO manages multiple web services (eg. Ubuntu
One and the software store), and it authorizes each *web service*
individually. Once a web service has been authorized, it can be used
by 200 different desktop applications without additional
authorization.

Even this division is only done because each web service has its own
TOC that the user must agree to. It has no real effect on security.

If we didn't want Launchpad to be an OpenID consumer, we could just
tie launchpadlib in to the Ubuntu SSO app. Then Launchpad's web
service would be one more service managed by Ubuntu SSO--and the
resulting system would have the same security properties as my branch.

4. There are some ways to improve the experience even more (such as by
auto-converting an Ubuntu SSO token into a Launchpad token if one is
found in the keyring), but this branch is a very easy first step that
will relieve a lot of pain.

Leonard

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