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

[Mark Seaborn <mseaborn onetel com>]

sampo nurmentaus movial fi wrote:

> > 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.

> Nice idea. I have also been thinking about running file chooser in
> a process of its own, to ensure that all the allocations it does
> are freed back to the system on a resource limitied device.

I'm not sure what you mean -- what sort of allocations?

> The way I tough it was that I need to creat a dialog that is
> run like any other dialog in the context of the  application in question.
> But then the contents of the dialog are provided by another process
> using GtkPlug/Socket. This provides you the possibility to
> provide the UI for selecting files from another process, while
> keepping the interface for the application programmer simple.
> 
> Haven't tried this in practice, so I don't know all the problems
> it might cause with key events etc., but if you are
> intrested in trying, please let me know.

I can't use GtkPlug/GtkSocket for this, for a number of reasons.

As I recall, the Xembed protocol that they use involves the process
that owns the parent window sending key press events to the process
that owns the child window.  This is no good if the powerbox's
security relies on the powerbox having a secure path to the user, such
that the application cannot supply the keypresses that enter the
filename!

Of course, the X Window System provides no security, so this is a
problem *anyway*.  The application process could send key press events
to the powerbox window and enter a filename, and thereby grant itself
access to any of the user's files.

I intend to address this by proxying each application's X11
connection, and having the proxy perform some access control so that
the constrained application cannot interfere with other X clients
outside of its protection domain (by sending events, sniffing key
presses, and so on).

That would break the Xembed protocol, which relies on X11's lack of
security.  In the long term, it would be possible for the proxy to
provide a mechanism for passing X window handles/references between X
clients (similar to the way file descriptor passing works), but apps
and libraries would need to be changed to use it.

So it is a lot simpler if the powerbox component opens its own top
level window!

Until there is an X11 security proxy, there will be a hole in the
powerbox's security, but the powerbox will still be useful and it
will demonstrate the concept.

Mark