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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
