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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
