Re: GMountOperation concerns

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-12-12 at 12:05 -0500, David Zeuthen wrote:
> Hi,
> 
> I've looked at the GMountOperation class today and I have some security
> concerns. Basically, the way I understand how it's supposed to work is
> that if you mount something you may need to provide credentials. Also,
> I understand a GtkMountOperation subclass is planned that can also fetch
> the credentials from gnome-keyring. 

That is not quite right. The gnome-keyring communication will happen in
the gvfs backends. All we need from the app is to reply to some
questions, like "what is the user name and the password? and btw whould
we save the password in the keyring?", or "the ssh fingerprint changed,
do you trust this new one?".

This goes through a GMountOperation for two reasons:
1) We can have multiple implementations of it, for instance a console
based text version and a Gtk based UI version
2) It is a way to separate out the lowlevel non-ui code from the X
dependent APIs in Gtk and still be able to get good UI integration. For
instance, the GtkMountOperation will know the correct parent for the
authentication windows, and it can implement things like application
modal password dialogs and inhibiting of "cancel" windows while a
password is being requested.

But I understand your concerns. You want a trusted path from the
keyboard to the authenticating entity. I think with some work we can
achieve that with the current system. Here is how it currently works:

1) App a wants to mount some gvfs volume, and the app hands gio a
GtkMountOperation.
2) We wrap this mount operation in a dbus mount operation that proxies
calls to/from the app mount operation to the dbus 
3) We pass the object path of this wrapper to gvfs in the mount call
4) when gvfs needs to auth it calls dbus -> wrapper mount op -> gtk
mount op -> user dialog -> gtk mount op -> wrapper mount op -> dbus ->
gvfs daemon

The same kind of wrapper is used on the gvfs side, the backend code just
sees a GMountOperation object which converts to/from dbus messages.

Now, how can we extend this to add a secure channel and not change the
API? One way is to make the GtkMountOperation object implement new
interface like GSecureMountOperation. The gvfs mount call would notice
that the passed in object implements this and call a different mount
operation that somehow returns a secure channel (via fd passing or
something) that gets passed into the GSecureMountOperation which spawns
a setuid helper. Another alternative is to pass the channel from the
GSecureMountOperation with the mount call.

On the client side apps will keep doing what they used to (pass
gtk_mount_operation_new() to the mount operation) and on the backend
side the code would still see a GMountOperation object, it would just
proxy things differently.

One problem is that GSecureMountOperation probably will need to expose
unix specific things (such as fd passing). But we can make this API
unix-specific and since the only consumer of it is in Gtk+ and its use
of it is hidden this isn't so much of a problem.

So, I don't think the current API prohibits a secure authentication
dialog, but it would be some work to implement.