GMountOperation concerns

[David Zeuthen <david fubar dk>]

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. 

I suppose the two main (and probably only) users who are here are the
file manager and the file chooser. As the latter runs in-process in any
application X it means the process space of application X can see the
passwords. This is pretty suboptimal especially considering that you may
not want to trust the application (e.g. closed source stuff using gvfs).

So, ideally, dialogs prompting for credentials should be as small as
possible and run in their own process space. With technologies such as
SELinux, and in the future XACE, one can ideally lock such applications
down insofar that no other process owned by the same user can interfere
with it [1] (e.g. use ptrace(2) or read it's memory). This is the
approach I've take for PolicyKit (which prompts for both user and
superuser credentials); basically the core fd.o PolicyKit library (which
is toolkit agnostic) defines an session-wide D-Bus service 

http://hal.freedesktop.org/docs/PolicyKit/model-authentication-agent.html

that desktops like GNOME or KDE or whatever can implement. For GNOME, I
have such an agent implementing this standard interface

http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html

and I know some KDE guys are working on a similar implementation for
KDE.

So I'm thinking a similar pattern would be useful for g_volume_mount();
it would move all credentials handling out of process. The downside is
that the application itself cannot draw it's own dialogs for asking for
credentials. But I think that's fine; we don't let gnome-keyring using
apps do this either.

Thoughts?

     David


[1] : Sure, this is _a lot_ of work and will require a "secure mode" for
toolkit libraries just like libc has a secure mode (which is forced for
setgid/setuid binaries etc). I understand this is currently not a goal
of GTK+ but someday it may be [2]. There's also lots of other attach
vectors; X11, a11y etc. etc.

The point is really that gio is toolkit agnostic and one may want to use
a secure toolkit, perhaps on a platform when using a secure windowing
system (e.g. not X11 or X11 with e.g. XACE).

[2] : I'm not really interested in starting a "should GTK+ have a secure
mode" thread; I fully understand all the issues and why it's like this
today.