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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
