ubuntu-phone team mailing list archive

[Tony Espy <espy@xxxxxxxxxxxxx>]

On 03/18/2013 08:50 AM, Alberto Mardegan wrote:
> Hi all!
>   I'd like to discuss about our plans for a password/secret storage
> service which could be used by applications to store and retrieve secret
> data.

Thanks for the write-up Alberto!

> On the desktop, we are currently using the GNOME keyring, which we
> cannot use as-is on UbuntuTouch given its dependency on Gtk+. The GNOME
> keyring itself implements part of the "Secret Service" freedesktop.org
> API [0], which AFAIK is also implemented by KDE's KWallet.
> 
> Whatever solution we choose, I'd recommend to expose an API compatible
> with the freedesktop.org's one; it might not be exactly what we need,
> but on the other hand I don't see a strong reason to do things differently.

+1

NetworkManager's nm-applet used to be a client of gnome-keyring,
although NM was re-configured in 12.04 to use systems settings by
default.  This means that currently, NM stores AP keys/passphrases in
cleartext connection files, which require root permission to read.

That said, according to our NM maintainer, this is currently slated to
switch back again to using the keyring by default, so sticking with a
compatible API is a good thing.

> That said, the next question is what we want to use; given that the
> "Secrets Service" API is not terribly complicated, and that the GNOME
> keyring is tied to Gtk+, I don't think that the effort of extracting and
> reusing the non-Gtk+ parts of the GNOME keyring is worth it.

Ah, the devil is in the details.  I wouldn't dismiss the benefits of a
stable working code-base so quickly.

The semantics already exist in code, the secure store piece is known to
be secure and works as advertised, and the PAM integration allows
gnome-keyring to operate without much intervention by the user.  This
wasn't always in the case in the past as others have pointed out.

That said, if we've done the analysis and determined that the UI code is
too tightly bound to the core logic, then that's another story...

> Someone suggested that we could implement the freedesktop API inside the
> signond daemon, which is at the core of Online Accounts; given that the
> daemon is easily extensible (it already provides an extension API for
> plugins), it might not be a bad idea, considering also that signond will
> be one of the main users of this API (it needs it to store account
> passwords and authentication tokens).
> However, while not being against the idea, I'd like to give it some more
> though before pushing it forward.

I can't say I'm a fan of this approach.  Yes, signond may be one of the
main clients, but to me, secure storage seems like a discrete concept,
and should be kept as a separate service.

Have you bounced this approach off of anyone in the security team?

> Another question is how the secrets DB should be stored. In MeeGo we
> were using the SIM "Run GSM algorithm" [1] to obtain a byte array which
> would be unique to the user's SIM, and use that as a LUKS key to decrypt
> the secrets storage which was mounted in its own loop partition.
> So the plan was to disable the password storage when the SIM was removed
> or deactivated.
> At the end we had to disable this feature because of problems with the
> SIM service (which from time to time reported that the SIM was being
> removed while in fact it was still there), but the infrastructure was
> all in place -- and as far as Online Accounts is concerned this is still
> usable, since we took off from the MeeGo code. Only the SIM interface
> needs to be re-written for oFono (provided that it can offer the same
> functionality).

As other have pointed out, not all devices running touch will have a SIM
card.

That said, it should be possible to implement this type of storage using
oFono's SIM API ( isn't this what Meego used? ).

That said, what does gnome-keyring use for it's store, and what
alternatives besides SIM have you considered?

> Anyway, regardless of what the access key is (whether it's the SIM or
> anything else, like a lock code or screen gesture), it might be a good
> idea to consider the possibility of having the secrets storage being
> made unavailable when some conditions are not met.

Sure, the secret-service document seems to already describe this as an
attribute of any service implementation.

> So, those above are a few aspects to consider. There are many ways to
> implement the secrets DB, and if you think you have more ideas, you are
> very welcome to list them here.
> I'm bringing up this discussion because this service is essential for
> Online Accounts (right now on UbuntuTouch our password database is not
> encrypted), and if there's something I can do to get this done,
> including writing code, I'd be happy to help.
> Consider this e-mail as me volunteering for this task -- but first we
> need to decide how to do it. :-)

Sounds like this is ripe for a blueprint.  Although the API
documentation is pretty complete, making sure the implementation is
properly specified and reviewed  ( including by folks from the security
team ) will be critical to it's success.

Finally, one last aside...  wouldn't full filesystem encryption remove
the need for a secret storage service?  AFAIK, it hasn't yet been
discussed in the context of Touch.

Regards,
/tony