Hi Leonard, On Thu, Sep 23, 2010 at 06:25:32PM -0400, Leonard Richardson wrote: > 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.
Right now, gnome-keyring-daemon acts as the gateway to my SSH and GPG keys. I can configure it to remember for the entire session, or a fixed amount of time, or moving window of time. Why can't this be done for per-application LP keys? > 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. My point is to have the option of separated permissions. If it doesn't get designed into the plan now, it will become increasingly hard to add it later. When someone is prompted, offer: [*] Allow this application [ ] Allow all applications [*] read access to LP [ ] read/write access to LP [*] public data [ ] public and private data [*] until this session ends [ ] until [__] minutes have elapsed [ ] until [__] minutes of being idle This is what gnome-keyring does for timeouts currently. There needs to be a way to _revoke_ the authorization too. It seems that writing a "Launchpad Agent" (like SSH and GPG agent) and hooking this backend to gnome-keyring would do the trick. > 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. Why not offer a non-browser way to do this? Gnome-keyring is effectively holding the "authentication token", and could go fetch a new "session token" for different applications, etc. Why confine the session management to the browser? > 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? I'm not worried about scary; everything is scary about desktop security currently. I'm worried about isolation and per-application access control so that in the future when desktop security gets a handle on scary, we can carve out the right permissions. It's like the difference between "sudo" being allowed to do _anything_ and specific PolicyKit rules defining precisely what exact action happens for a given person/group/etc (bring up wifi, talk to scanner, etc instead of "run anything as root"). Users should be able to say "*this* application can read LP, and *that* application can write to LP". > (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?) I'm advocating for fine-grained controls being possible since they have value in places that aren't specifically malware-defense. -Kees -- Kees Cook Ubuntu Security Team _______________________________________________ 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
