launchpad-dev team mailing list archive

[Kees Cook <kees.cook@xxxxxxxxxxxxx>]

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