launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

I think I can summarize/restate Leonard's plan as:

 * We will recommend that desktop clients store their token in the
desktop keyring (GNOME Keyring, KWallet, Mac OS Keyring, ...), and
facilitate this in launchpadlib/etc.

All the policy decisions about how the token is unlocked, which
applications have access, etc, are then delegated to the keyring.
Desktop keyrings are commonly configured so that secrets are unlocked
for a certain time and all local applications can read them, perhaps
with a prompt.  Users can tweak this to their convenience:security
taste, and over time the implementation may get better as we get app
signing etc.

So it's not so much that we're trusting the desktop as that we're
giving the user a key, which they will then probably store on their
keyring.  It is likely that this will then effectively authorize the
whole desktop, but whether it does or not is up to the user (or the
default keyring policy.)

I think this is a much better plan because it gets Launchpad out of
the business of trying to do things it's poorly-place to do, such as
discriminating between different desktop applications.  It's still a
work in progress to do that securely locally but it's pretty much
impossible to do it over the network.  People who want to work on
those problems can do them in a place like GNOME Keyring or KWallet
that helps the whole desktop, not in an lp-specific reimplementation.

Once the keyrings are able to strongly discriminate between
applications, we might want to give different applications different
levels of permission.  This seems feasible within the keyring
architecture.  It seems to me that for this to be really compelling,
we'd need finer-grained permissions architecture within Launchpad: at
the moment I think it's fair to classify apps as either trusted or
not.  We're still working on step 0, making the process smooth for
trusted apps; then step 1 is to safely exclude malicious apps that are
somehow running on your desktop; then later we can get into minimum
privilege.

I don't see how it is in any sense aiming low, but I'd like to know
more.  It seems like we can meet all of Robert's issues in this
architecture.

If that's an accurate summary it does have a couple of consequences:

* If, for the typical case, we want to do just one-time authorization,
users will probably want to get the maximum normal permission at that
point, ie WRITE_PRIVATE, even if that's more than is needed by the
first Launchpad app they run.  This has consequences for the lplib
api, ie is the client program asking "give me a key with at least
this" or "with exactly this"?

* This makes it a bit more important that Launchpad store and display
the client hostname to which a key was granted (for which there is a
bug).  For that matter letting you see the last time they were used
would help gardening them.

* There are some security-criticial operations like adding ssh keys,
for which we may want special treatment like a short-lifetime token or
an email confirmation.  Either way, it would fit with using the
keyring.


On 3 October 2010 08:40, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> Thank you for revisiting this Leonard.
>
> I agree that plain unsecured files on disk are not as robust or secure
> as gnome-keyring.
>
> Key takeaway: If Kees and the Ubuntu security team are ok with this,
> great. Do it, and sorry for the interrupt I raised (though I think it
> was worth raising).
>
> I have a few minor things you might like to consider.
>
> We support KDE via Kubuntu and many Ubuntu developers use it;
> gnome-keyring seems rather specific; can we, as Sidnei suggests, use
> an abstraction layer to provide the benefits [currently only
> encryption?] to those environments too?
>
> Your passion for 3rd party developers needs its awesome, but this
> design seems to be aiming at an unsatisfactory place.
>
> We *have* had credentials for key members of Ubuntu compromised in the
> past (through them pasting a openid cookie IIRC) and that route
> remains unaltered. The change that you're doing makes oauth roughly
> the same as openid cookies.
>
> My experience with software design is that when we aim low, we achieve
> low. I may simply be missing roadmap documents but the bigger picture
> seems to be missing (to me).
>
> So I have a challenge for us and our authentication and access control stories:
>
> Aim High.
>
> Perhaps we should set a vision for what we'd like to achieve here:
> Single sign on (web, casual apps, daemons like Ubuntu One), persistent
> credentials (if the user wants - I would!), easy authorisation of new
> apps (single clicky clicky dialog, in some trusted computing base),
> timeouts (defaulting on for high privilege levels), powerful per-app
> controls (like the openid prompt which says what is being disclosed),
> and only one protocol needed (rather than two, managed separately but
> with equivalent issues).
>
> We can then look at the stack, at what needs doing, and work it up.

-- 
Martin