launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part