conversation on irc about it
#gnome-hackers
   [17:03:16]  <stefw> halfline: ping
   [17:03:52]  <halfline> stefw: pong
   [17:04:07]  <stefw> halfline: hey, i saw your post about system modal
   dialogs
   [17:04:24]  <stefw> cool stuff. i'd like to discuss with you about
   integrating gnome-keyring password stuff into the shell.
   [17:05:15]  ***  MacSlow has left chat #gnome-hackers (So long and thanks
   for the fish!).
   [17:05:28]  <stefw> halfline: specifically the password prompts
   [17:05:47]  <halfline> sure
   [17:06:14]  <halfline> the keyring dialog seems like obvious example where
   we need a system modal dialog i think
   [17:06:21]  <stefw> yeah seems like a good fit.
   [17:06:29]  <stefw> there's one or two wrinkles, like how we encrypt
   passwords before they pass over ipc...
   [17:06:40]  <stefw> how we use non-pageable memory
   [17:06:54]  <stefw> and the various choices the user can make for how to
   cache their password
   [17:07:43]  <stefw> so i wanted to get in on the design phase and help
   either make the shell password prompts usable by gnome-keyring, or figure
   something out.
   [17:08:22]  <halfline> right makes sense, i wonder if javascript has a way
   to mlock a region of memory ...
   [17:08:38]  <stefw> probably doesn't make sense for javascript to do that
   bit.
   [17:08:40]  <halfline> at this point i've been coming at things mostly
   from the "logout dialog" angle than the password dialog angle
   [17:08:56]  <stefw> i imagine that we'd write a component in C for the
   mlock stuff, no?
   [17:09:05]  <owen^ there have been various conversations with mccann,
   dcbw, and tbzatek about password prompting in the shell world recently,
   maybe mccann can turn those into guidelines on the wiki later this week
   [17:09:14]  <owen> (still the question of how to turn intent into code)
   [17:09:33]  <stefw> cool. i'd like to get involved in that.
   [17:09:39]  <halfline> stefw: so right now entries are done using a
   toolkit called St
   [17:09:47]  <stefw> owen: looking forward to the wiki page
   [17:09:55]  <halfline> it has a StEntry widget, so i imagine the mlock
   stuff will need to go there
   [17:10:00]  <halfline> it's written in C
   [17:10:05]  <stefw> halfline: right
   [17:10:27]  <stefw> and gnome-keyring uses DH+AES to secure stuff
   passwords that flying over DBus
   [17:10:36]  <halfline> although looking through it on the spot here, it
   looks like it may wrap a ClutterText, so we may need to go a level lower
   [17:10:37]  <stefw> since we can't expect every component along the way to
   use mlock etc...
   [17:10:46]  <stefw> that's already worked well to keep passwords out of
   logs for instance.
   [17:11:01]  <owen^ what's the point of that? if the memory of dbus-daemon
   gets swapped out?
   [17:11:20]  <walters> yeah
   [17:11:22]  <stefw> owen: swapping, logging, caching and other stuff.
   [17:11:24]  ***  danilo (~danilo@138.210.92.194) has joined chat
   #gnome-hackers.
   [17:11:34]  <stefw> its already saved our asses once. where logging was
   enabled on ubuntu by default.
   [17:11:42]  <stefw> logging of ipc, that is.
   [17:12:13]  <stefw> halfline: i like that we're designing with the goal of
   trusted path UI stuff.
   [17:12:20]  <halfline> stefw: another idea is there's no reason this
   communication needs to be entirely over the session bus
   [17:12:20]  ***  gregier1 has left chat #gnome-hackers (Leaving.).
   [17:12:30]  <stefw> halfline: true
   [17:12:35]  <halfline> could just use the session bus to initiate a
   peer-to-peer connection or something
   [17:12:46]  <stefw> but then you have to come up with another method
   that's immune to caching, logging, swapping etc.
   [17:12:47]  <owen^ I guess you could write a Shell.EncryptingPasswordEntry
   which only had an encrypted getter. Though I'm a little confused about how
   the encrpytion process is bootstrapped
   [17:12:50]  <halfline> the thing is, the communication between service and
   dialog is entirely private after all...
   [17:12:54]  ***  RAOF_ has left chat #gnome-hackers (Remote closed the
   connection).
   [17:13:04]  ***  gregier (~gregier@c-76-115-15-6.hsd1.or.comcast.net) has
   joined chat #gnome-hackers.
   [17:13:18]  <stefw> owen: i can write up a page on how it works with the
   current gnome-keyring-prompt
   [17:13:54]  <stefw> but basically it uses dh to do key exchange.
   [17:13:57]  ***  bratsche has left chat #gnome-hackers (Ping timeout: 600
   seconds).
   [17:14:12]  ***  MacSlow (~mirco@138.210.92.194) has joined chat
   #gnome-hackers.
   [17:14:18]  <stefw> owen: but the DH key exchange fits along with the
   prompt() call
   [17:14:34]  <stefw> we pass the dh parameters along with the call, and get
   dh parameters + encrypted response back
   [17:14:41]  <stefw> so there's not extra back and forth.
   [17:15:16]  ***  RAOF_ (~RAOF@138.210.92.194) has joined chat
   #gnome-hackers.
   [17:15:17]  <stefw> halfline: when designing the 'Secrets Service API' for
   password storage and retrieval, we found it simpler to use DH key
   exchange, than a private comm channel
   [17:15:24]  ***  balor has left chat #gnome-hackers (Read error: 131
   (Connection reset by peer)).
   [17:15:25]  ***  janm has left chat #gnome-hackers (Read error: 145
   (Connection timed out)).
   [17:15:28]  <stefw> but you're right, that this could eb purpose built
   since it's only implemented in one place.
   [17:16:11]  <owen^ mm, well, it's going to be ugly, but certainly
   possible. Anything that you pass over dbus can be shoved into a C-based
   Shell.EncrpytingPasswordEntry, and anything that the
   Shell.EncrpytingPasswordEntry returns can be shoved back over JS along
   with the encrpyted password
   [17:16:53]  <stefw^ yup it adds complication. but keep in mind that stuff
   like trusted path prompting is going to be way more ugly.
   [17:17:16]  <owen^ we have to be very careful to make sure that we know
   our goals
   [17:17:24]  <owen> and don't add complexity to the user for stuff that's
   marginal
   [17:17:32]  <stefw> right, for sure
   [17:17:49]  <stefw> but here's a case where we're trying to integrate
   gnome-keyring into the shell (which i think is a good goal).
   [17:18:00]  <stefw> to do that we need to make sure we're not reducing
   security if at all possible.
   [17:18:16]  <stefw> the security goals of gnome-keyring are well defined:
   http://live.gnome.org/GnomeKeyring/SecurityPhilosophy
   [17:18:23]  <owen^ I'm definitely not sold out of the box on hte value of
   trusted path. "Keeping your password out of swap" seems legitimate though
   really, 'cmon. just encrpyt your swap, you don't want your private emails
   in there either
   [17:18:56]  <stefw^ true. trusted path is pie in the sky and i guess we'll
   see how/when/who works on that.
   [17:19:20]  <owen^ nice wiki page
   [17:19:21]  <stefw^ and yes it'll need to be considered carefully to see
   if it's worth it or not.
   [17:19:27]  <stefw> thanks
   [17:19:55]  ***  mccann has left chat #gnome-hackers (Ping timeout: 600
   seconds).
   [17:19:57]  <stefw> here are the implementation goal/tasks for "preventing
   information leakage"
   [17:20:00]  <stefw>
   http://live.gnome.org/GnomeKeyring/Goals#Goal:_Preventing_Information_Leakage
   [17:20:00]  ***  BlanchardJ (~jo@142.167.111.151) has joined chat
   #gnome-hackers.
   [17:20:28]  ***  rodrigo (~rodrigo@138.210.92.194) has joined chat
   #gnome-hackers.
   [17:22:37]  <halfline> stefw: so i'm going to first finish up working on
   the logout dialog, then move to the shutdown dialog and after that i'm
   going to jump into the various password dialogs (policykit, gnome-keyring,
   etc). I'll make sure i ping you and we can chat more about the specifics
   then
   [17:22:50]  <stefw> halfline: great.
   [17:23:05]  <stefw> rock on!

Follow up messages in bugzilla from owen
https://bugzilla.gnome.org/show_bug.cgi?id=637187#c11
Owen saying in reply to comment #10)
> - Keyring dialogs -> should not use DBus to keyring, or else should use peer
> connections
> - other password dialogs -> what to do?
> 
> The main problem is that there is no memlock in JS, so we have no way to secure
> secrets and password going through Javascript UIs (including WPA keys, keyring
> passwords, root passwords...).
> Other problems are code duplication (reimplemented) vs. code bloat (delegated),
> safety of DBus API, stability of internal protocols and libraries.

I talked some to Stef Walters about the keyring dialog. My understanding is
that the way it works currently is that the keyring daemon, when it needs a
password, negotiates encryption keys with the password dialog using
Diffie-Hellman key exchange to allow passing the password over DBus without the
risk that the DBus message containing the password would be swapped out to disk
when being processed by the D-Bus daemon. We can simply extend the length of
time that the key is encrypted so that we have:

 ShellPasswordEntry <=> js <=> dbus <=> gnome-keyring-daemon

 Where the password is encrpyted by the ShellPasswordEntry (written in C, using
 memlock) and never decrpyted until it gets to gnome-keyring-daemon.

rough couple of hours gnome-shell start i did a while ago: http://www.gnome.org/~halfline/keyring-goo.patch
Unfortunately, I lost the gnome-keyring half of this code at somepoint so it's not really that useful.

