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

[Mark Seaborn <mseaborn onetel com>]

Mike Hearn <mike plan99 net> wrote:

> Hi Mark,
> 
> I've looked briefly at this before. A few thoughts:
> 
>  * Rather than messing around with LD_PRELOAD and X proxies you really
>    just want to build your own patched copy of GTK+. This sort of change
>    is fundamental and not something you should try and layer over an
>    existing system. For X security you need to look at SE-X, which is
>    SELinux but for the X server.

Let's separate the issues of LD_PRELOAD and X proxies.

The reason for using an LD_PRELOADed library to replace Gtk's
GtkFileChooserDialog is mainly to save people the trouble of
rebuilding Gtk, and so that the patch will work with any
ABI-compatible version of Gtk.  So far it seems that there is no need
as such to build it into Gtk (unlike Plash's libc changes, where
libc.so *does* need to be rebuilt).  It doesn't make any difference
for the security of the system.

Eventually it would be good if the powerbox code could be merged into
mainline Gtk.  Until then it should be as convenient to use as
possible.


As for X security, I've been looking at the XACE (X Access Control
Extension) and XSELinux extensions.  It doesn't look like they will do
what I want.  It seems that XACE just provides a set of hooks,
internal to the server, which XSELinux uses.  So in order to do access
control between X clients (without depending on SELinux), you'd need
to write a new extension that hooks into XACE.  It would take a long
time to get it into the mainline X server, and until then, you'd need
to port it between X server versions, and people would have to build
patched X servers.

The advantage of an X proxy is that it will work with everyone's X
server and everyone's kernel.  It allows for some experimentation over
how fine-grained access control should work for X resources.  It's
less invasive.  The down side is, of course, performance, so
ultimately it's desirable for this to go into the X server.


>  * This problem is a specific form of a more general one, which is how to
>    separate submodules of an existing monolithic C/C++ codebase into
>    separate processes which run in separate security contexts. Not
>    co-incidentally, this is the subject of my university dissertation.

What approach are you taking?

>    I'm intending to make the resulting RPC framework available under an 
>    appropriate license once I have finished my degree. So far the RPC API 
>    is quite simple and easy to integrate with existing apps (it's a
>    typeless/IDL-less system) and I think a PowerBox implementation for GTK+
>    would be a good application of it.

Plash also has an RPC system.  It has an object invocation protocol in
which an object invocation consists of a data portion, an array of
object references, and an array of file descriptors.  It is typeless
in the sense that the protocol does not prescribe a format for the
data portion.

>    This goes some way towards solving the problem of proxying
>    gtk_window* calls to the remote process.

I don't really intend to proxy gtk_window* calls.  The application
shouldn't treat the powerbox as a window.  The powerbox-request
object's method doesn't have any notion of windows.  (One exception is
that eventually it should be possible to specify an X resource ID as
the powerbox's parent window.)

>  * A Plash independent way to do this is have the PowerBox open the file
>    itself, then send the file descriptor across the RPC connection. Then
>    get_filename can return /proc/self/fd/$x and everything should work as
>    normal except that displaying the filename in the title bar etc
>    wouldn't operate correctly.

Displaying the incorrect filename is quite a big problem.

Hmm, /proc/*/fd has some curious semantics.  Although the entries
pretend to be symlinks, the kernel doesn't use the symlink destination
text when following the symlink.  Furthermore, doing
open("/proc/self/fd/N", XX) is *not* equivalent to doing dup(N),
because it will return a different file descriptor for the same file
with a different file position.

If you took this approach, the main question would be, how are you
going to take authority away from the application process and isolate
it from other processes?  chroot() and setuid() is a good answer, in
the absence of kernel patches.  But I'm not sure that /proc/self/fd/N
will work in this case -- I looked at the kernel source and it seems
to do a UID check of the file whose file descriptor is being copied.
However, I didn't test it, and I don't know what the semantics are
supposed to be (is it documented anywhere?).

Mark