launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Thank you very much for sending this.

I want to address something up front, which I think there is perhaps
confusion on.

I'm fine with the process you followed: as I said at the epic, we
can't scale as a team if any part of the process bottlenecks, and
talking to e.g. me first in any mandatory sense would bottleneck
eventually.

I'm a strong believe in iterating and tweaking; as far as I'm
concerned our process is working: something that sets of alarms had
sufficient examination to be pulled out of the queue for closer
examination.

I think it would have been a *good idea* for this particular thing to
be socialised more, particularly with the Ubuntu security team and
other Launchpad API developers, but I couldn't reliably describe in
advance every patch that would need such socialisation.

Anyhow, its getting it now.

I've copied Kees on this, as a way to get him to eyeball it - he might
not have time, or might want more of the Ubuntu security team to be
involved, but I'll let Kees make that call :)

My specific concerns here are:
 - will launchpad be safe for our System administrators to use?
 - will it be safe for our archive administrators to use?
 - will it be safe for any privileged user to use?

AFAICT the answer is no; with the intended design satisfied any rogue
script can drive a tractor across all of launchpad as that user, and
*thats* why I put the breaks on.

-Rob

On Fri, Sep 24, 2010 at 4:20 AM, Leonard Richardson
<leonard.richardson@xxxxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp
>
>