[Plash] Plash 1.14: file powerbox added

[Mark Seaborn]

There's a new version of Plash available, 1.14.
You can get it from:  http://plash.beasts.org

I didn't get around to announcing the last two versions on this list,
but to summarise, the changes were:
 * Added the pola-run program (which I initially proposed to be called
   "plash-exec").  This is a programmatic command line interface for
   starting programs under the Plash environment, an alternative to
   the shell.
 * Made it much easier to build Plash from source by providing pre-built
   object files for glibc, and changing the build process to use them.
   Upgraded from glibc 2.3.3 to 2.3.5.

The new feature in this release is file powerboxes.  Here is the
documentation from the readme file:


Powerboxes are a design pattern for dynamically granting authority to
a process.  A file powerbox works just like a "File Open" or "File
Save" dialog box from the user's perspective.  The difference with a
powerbox is that as well as naming a file, it grants the application
instance that opened the powerbox the authority to access the file.

Plash comes with an Emacs Lisp module which changes XEmacs to use a
powerbox.  In order to run XEmacs this way, you can use:

pola-run --prog /usr/bin/xemacs -B -f /etc --cwd / \
  --powerbox --pet-name "XEmacs" --x11 \
  -a=-l -a=/usr/share/emacs/site-lisp/plash/powerbox.el

The powerbox.el file replaces XEmacs' read-file-name function, which
usually prompts for a filename using the minibuffer.  Typing C-x C-f
(for example) will now bring up a "File Open" dialogue box instead.


NB. This functionality is separate from the previously-existing
plash-run-emacs, which provides gnuclient-like functionality for
granting files to an XEmacs process.  plash-run-emacs and the powerbox
do not work together at all.  I have to work out a design to integrate
them.  The powerbox code is *not* specific to Emacs.  I intend to
generalise plash-run-emacs so that it can be used with programs
besides Emacs.


How it works
------------

The powerbox manager is compiled into the pola-run program launcher.
When the --powerbox option is used, pola-run will pass the application
being launched an object under the name "powerbox_req_filename".

An application can invoke the object powerbox_req_filename to
request a file from the user.  In response, the powerbox manager will
open a "file open" or "file save" dialogue box.  If the user selects a
filename, the powerbox manager attaches the file (or file slot) into
the application's file namespace, and returns the filename to the
application.

When the application invokes powerbox_req_filename, it can pass some
arguments, such as:

 * Whether it wants a file or a directory.
 * Whether it is opening or saving a file.
 * A textual description of why it wants the file.
 * A start directory.  The powerbox manager checks that this
   directory is already in the application's namespace, so that the
   application can't confuse the user into granting it the wrong file.

There is a simpler helper program called "powerbox-req" which invokes
the powerbox_req_filename capability.  It is a command line program,
so it is easy to use from XEmacs.

The --pet-name argument provides a name for the powerbox manager to
put in the title bar of the powerbox, so the user can tell which
application the request comes from.

The powerbox manager uses Gtk to provide a file chooser.


Limitations
-----------

The biggest limitation is that the X Window System provides no
security!  The security of a powerbox rests on the idea that it has a
secure path to the user: Only the user can enter a filename using the
powerbox.  But under X11, this isn't true: one X11 client can spoof
keypresses by sending keypress events to another client.

Under X11, there is a bit in the keypress event that distinguishes
genuine keypress events from those generated by other clients.
However, this bit is rarely examined by applications -- it's not clear
what you'd do with it most of the time -- and this includes Gtk, which
the powerbox manager uses.  Having the powerbox manager this bit would
not be very useful because a malicious application could still gain
authority by sending events to other X11 clients.

A proper solution will be to proxy the application's X11 connection to
isolate it from other clients.


There is currently no way to review what authority has been granted to
applications using the powerbox, and no way to revoke this authority.

Nested use of pola-run with the --powerbox option is not very useful
at present: the nested instance of pola-run will provide its own
powerbox manager.  At the moment, the powerbox_req_filename object is
only able to attach a file into an existing file namespace and return
a filename.  It needs to be extended so that it can return a reference
to a file or slot object.  Then the nested instance of pola-run can
attach this reference into the namespace it created.

As it stands, using Gtk's file chooser, the powerbox does not provide
a secure UI for handling Unix symlinks.  The user is not shown symlink
destinations at all, yet the powerbox manager will follow symlinks,
even though the symlink destination could have been provided by the
application.  The answer here is to change the file chooser to display
symlink info, and perhaps require the user to double click on a
symlink to follow it.

The UI doesn't give a way to attach a file under a different filename.

No way is provided for adding a file to the application's namespace
except in response to a powerbox request, which would be useful for
"gnuclient" style programs.

Backup files are not handled.  Arguably, when the user chooses <FILE>,
the powerbox should also grant access to "<FILE>~" and "#<FILE>#" (the
latter is used by Emacs' auto-save feature).


To do
-----

So far, the powerbox has only been integrated into XEmacs.  The aim is
to integrate it into other applications.  For Gtk programs, this could
be done by replacing Gtk's FileChooser widget.  There may be some
complications for applications that expect FileChooser to be a real
window, rather than something that just does a remote object
invocation.


References
----------

[This needs filling out fully.]

 * Ka-Ping Yee and Miriam Walker, "Interaction Design for End User Security"
 * CapDesk