Re: gnome-keyring GNOME keyring without Gtk+

[Stef Walter <stefw gnome org>]

On 03/25/2013 09:28 AM, Alberto Mardegan wrote:
> Hi Stef,
>   thanks for your reply. Comments inline.
>
> On 03/21/2013 09:53 PM, Stef Walter wrote:
> [...]
> > I'm not against collaborating on gnome-keyring with someone who has
> > non-GNOMEy goals, while at the same time I want to make sure we don't
> > give up on the integrated GNOME experience. I think we can accomplish this.
>
> Agreed.
>
> [...]
> > The password is passed over dbus using GcrSecretExchange to prevent
> > accidental logging or paging to disk as it goes into dbus marshalling
> > and on the wire. [3]
>
> What is it actually doing? Is it encrypting/decrypting the reply?

Yes, the password.

> I had a look at the GrcPrompter D-Bus interface and was wondering if we
> could just standardise that, since it looks pretty simple; maybe turning
> it into a D-Bus p2p channel would simplify the API even more (no need
> for explicit callbacks and encryption).
> Let me know if this is something worth exploring.

Yes, if there's going to be another implementer of the API, perhaps we
should.

I previously went to great lengths to keep passwords out of pageable
memory. But as you can see that did complicate things. I've been pushed
to to compromise a bit on this these days, and consider alternatives
because:

 * Kernel DBus will do zero-copy, and not be trivially snoopable.
 * Prompters are written in code like javascript, which make no
   guarantees about the memory they use to store passwords.

However, we should still give thought as to whether we can make this
guarantee using an architecture:

 * When the user is not using the computer (locked/sleeping/off) the
   keyring password should not be sitting on the same disk as the
   encrypted keyring.

Not that all implementations can make that guarantee, but in my opinion
it's worth making sure it's possible.

> > gcr supports introspection, but not sure if that helps toward making a
> > QT prompter.
>
> Not at the moment; however I don't think it would be a very complicated
> wrapping even if done manually (the only bit which worries me is that
> the register method takes a GDBusConnection, and AFAIK there is no way
> to create a GDBusConnection object out of an existing libdbus
> DBusConnection, which we could get from QtDBus).

I see what you mean.

But since it's just the prompter process, it's not the end of the world
if it connects to the bus twice.

> > However I've been working on plans to make autologin work in a secure
> > but prompt-less manner by integrating with a TPM chip. This would allow
> > us to exit in that case, and then unlock the keyring using the TPM when
> > coming back.
>
> Where would this integration take place? On the keyring or on the prompter?
> Anyway, if we reimplement the GcrSystemPrompter, the fact that GNOME
> keyring asks for the master password would not be a big issue, if the
> prompter implementation is able to read the password from somewhere else
> and not ask the user.

I had imagined it as using a public key to encrypt decrypt the keyring,
and not just the password. But that is an alternate implementation that
is perhaps simpler.

Doing it the way you suggest, however puts further pressure on us to
secure (appropriate to the use case) the mechanism we use to pass
passwords over dbus from the prompter.

> [...]
> > Again the reason for this is because I'd like more steady non-me
> > contributions to gnome-keyring.
> >
> > So if being open to steady contributors that want make gnome-keyring
> > work well to use in a non-GNOME environment is what it takes to get
> > contributors, then I'm willing to compromise on certain things that I
> > wouldn't otherwise care about if I had a GNOME only mindset.
> >
> > Let's see if my gambit pays off, hint, hint... :D
>
> Crystal clear. :-)
>
> On Thursday we are having a hangout OnAir about the secret storage
> implementation for the Ubuntu phone/tablet:
> http://joseeantonior.wordpress.com/2013/03/20/secure-credentials-storage-on-the-phone-on-air/
> If you could make it, that would be great; there might be some questions
> about changing some behaviours of the keyring which we have not yet
> covered here.

Sure. I think I can make it. I have a test day for my certificate
integration work [0] [1] on that day [2], but I can probably step away
from that for a short time.

Do I need to register somehow?
https://plus.google.com/109966160795843627457

Cheers,

Stef


[0] http://p11-glue.freedesktop.org/trust-module.html

[1] Which Ubuntu should obviously use ;)

[2]
https://fedoraproject.org/wiki/Test_Day:2013-03-28_Shared_System_Certificates