Call-return interface for file choosers? (and: security using powerboxes)

[Mark Seaborn <mseaborn onetel com>]

I want to create an alternative implementation of GtkFileChooserDialog
that doesn't implement a file chooser window itself, but instead
invokes an external, trusted process to provide a file chooser.  This
is for security purposes -- skip ahead for more on the reasons.

Basically I want to treat GtkFileChooserDialog as an asynchronous
call-return interface, so that:

 * gtk_widget_show() on the GtkFileChooserDialog sends a message to
   the external process asking it to open a file chooser.  The message
   will contain the start directory, default file leafname, etc.
 * When user chooses OK/Cancel, the external process replies and the
   GtkFileChooserDialog invokes the GtkDialog response signal.
   The filename is returned so now gtk_file_chooser_get_filename() can
   return a result.

Obviously the interface wasn't designed with this in mind.  It is a
shame that Gtk doesn't also provide a simpler file chooser interface
that omits control over the dialog box while it is open.  (Contrast
this with Qt and Windows, which do offer such call-return style
interfaces.)

Does anyone have any thoughts on the best way to implement this?  The
tricky part is that an application can expect a GtkFileChooserDialog
to be a GtkDialog, a GtkWindow, a GtkWidget, etc., and could
potentially call the methods these provide.  Is there any way for an
object to implement these interfaces without it using the usual
implementation for GtkDialog, GtkWindow, etc.?  If this isn't
possible, perhaps the simplest thing to do is have
GtkFileChooserDialog create a dummy window that won't allow itself to
be shown.


Here's why I want to do this:

I am working on improving security by making it practical to run GUI
programs in a least-privileges environment, so that an application
does not have to be run with all the user's authority and access to
all the user's files.

This requires a way to dynamically grant a process access to further
files after it has been started.  Fortunately, this does not require
any change in user interface.  File choosers work fine for this
purpose.  They gain a new security role: as well as providing the
selected file's name to the application, a file chooser grants the
application the right to access the file.

For this to provide security, the file chooser can't be implemented by
the application and its libraries.  It must be implemented as a
separate, trusted component, and it must run in its own protection
domain.

The idea is that the file chooser has a trusted path to the user, so
only the user can enter a filename into it.  This allows the system to
distinguish between requests made by the user and requests made by the
application.

This kind of file chooser is known as a "powerbox".  Powerboxes have
been implemented in a couple of systems already: CapDesk
(http://www.combex.com/tech/edesk.html) and Polaris
(www.hpl.hp.com/personal/Alan_Karp/polaris.pdf).  CapDesk is based on
the "E" language, implemented in Java, while Polaris is a restricted
environment for running Windows programs.

I am implementing powerboxes using Plash (http://plash.beasts.org),
which is a restricted execution environment for running Linux
programs.  It provides a way to grant a process access to files
selectively.  I have already implemented powerboxes for Emacs: this
works by replacing the read-file-name function.

Note that the powerbox pattern does not require any confirmation
dialog boxes asking questions of the form "Is it okay to let app
<blah> open ~/foo.txt [y/n]?".  These don't really provide any usable
security, because they just train the user to press "OK" all the time.


Here's a concrete example of how this security works:

Suppose you run Gnumeric to view a spreadsheet you downloaded from the
Internet.  Gnumeric might not be a malicious program, but suppose it
has a buffer overrun bug (quite possible considering it's written in
C), and the spreadsheet exploits that bug.

If Gnumeric runs with all your authority, the dodgy spreadsheet can
read your files (perhaps the contents of ".ssh") and send them back to
its creator.

But if Gnumeric runs with minimum authority, the malicious spreadsheet
can't do anything except write to the file it was opened from, and
open a powerbox to request a file.  The application cannot specify a
default pathname for the powerbox to open, so for the spreadsheet to
get access to a sensitive file, the user would have to specifically
choose that file.  The malicious spreadsheet would find it very hard
to get access to ".ssh": why would the user choose ".ssh" if Gnumeric
opened a powerbox out of the blue without a good reason?

Mark