Thanks for your responses. I have a couple follow-up questions for Kees and Robert.
First, Robert, one of your concerns is with making the web service safe for privileged users to use. I believe it's possible to configure the GNOME keyring so that the keyring is never permanently "unlocked". Any attempt to access a key from the keyring will require that you enter your keyring password. If you didn't just do something that requires accesss to one of your keys, you don't enter your password. I imagine it would be very annoying to live with this kind of setup. But that's the setup I'd live with if I were totally serious about protecting my SSH keys and OAuth tokens from malware. How close would this come to making you feel that your OAuth tokens were safe? And, Kees, how much would this actually improve security? > Using sensibly short timeouts for session tokens as a default is good. > I'm not opposed to making "forever" available for those that want it, > but it should probably not be the default. We do plan to add timeouts for session tokens in two circumstances. (These are both mentioned in the design document I linked to last time, http://pastebin.ubuntu.com/499131/) Here's the one that pertains to my last two questions: There are a couple actions (uploading SSH/GPG keys) that are so fraught with peril that we currently don't publish them on the web service at all. We plan to publish these operations but only make them accessible through time-limited OAuth tokens that have a new permission level. Normal "desktop integration" permission will not be good enough to use applications that upload new SSH keys, like Quickly. You will have to do the browser dance and get a brand new time-limited token every time you want to upload a new SSH key. Now, suppose we take existing web service operations like "toggle whether this bug is a security bug" or "toggle this bug's public flag". Things that we're kind of worried about, but not so worried that we were afraid to publish them at all. And we put those in the same category as "upload a new SSH key". A category that forces you to do the browser dance every 15 minutes as long as you're doing that kind of thing. And added some code that kept those keys from being stored in the GNOME keyring, making it more difficult for malware to grab them. Robert, how far would *this* go towards addressing your concerns about making the web service safe for privileged users? Think about what you're most afraid of when it comes to malware acting as a privileged user. Are you afraid of things that only privileged users tend to do? Things like uploading SSH keys and changing the security status of bugs? Or are you afraid of things that everybody does all the time, but that can be especially damaging when privileged users do them? This brings me to my third question. Imagine that the existing system really did work the way I imagined it could, before I found out about the GNOME keyring. Imagine that when you grant an OAuth token to apport, apport is the only application that can see or use that token. You have to authorize every one of your desktop apps individually. It works like a dream. Here's the problem: my developers will not put up with that. They don't put up with it now, and they won't suddenly start putting up with it if the security benefits ever become real. Pretty much every third-party developer (and at least one internal developer) has responded to our OAuth token authorization protocol by hacking around it, creating some native-GUI way of asking the user for their Launchpad username and password, so that their users don't have to do the browser dance. That's the whole reason I'm trying to change this system--my customers simply refuse to make their users do the browser dance before using an application. Making the tokens time-limited, or making the permissions more fine-grained, will just make things worse, as developers try harder to find workarounds. The system we have now, for all its shortcomings, is intolerable to my developers. I'm trying to find a system that's at least as secure and that can get developer buy-in. My proposed design seems congruent with existing Ubuntu best practices when it comes to your SSH keys and the data you've got stored in Ubuntu One. The only realistic alternative I can think of is to enforce draconian rules like "we won't let your program into Ubuntu unless it does the browser dance properly, but you can tell your users to blame us for the bad user experience." And now, finally, my third question. Suppose we were to move the "scary" activities into a time-limited token, a token that required a browser dance every fifteen minutes but which ordinary users would rarely need to acquire. Would it then be below the scary threshold to manage your ordinary activities on the web service with a single, desktop-wide token? (And, to restate my second question, would there be enough "non-scary" activities left that an ordinary user would not find themselves constantly doing the browser dance to get privileged tokens?) Leonard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
