Fine-grained access control -- XACE, XSELinux and X security

[Mark Seaborn]

Is there any documentation for the XACE and XSELinux extensions?
What is their current status?

I am interested in this because I have been working on a restricted
execution environment for Linux programs called Plash
(http://plash.beasts.org).  I am currently working on making this
applicable to GUI programs.

One aspect of this is providing a security-conscious version of file
chooser dialog boxes -- called a "powerbox" -- in which the file
chooser grants the right to access the chosen file to the application
that opened the file chooser.  This means that the app can start off
without access to any of the user's files.

The powerbox must be implemented separately from the application; it
is a trusted component, running in its own protection domain.
Applications or their libraries need to be changed to use the powerbox
rather than provide their own file chooser.  So far I have patched
Emacs to use the powerbox.  I'm now working on replacing Gtk's
GtkFileChooserDialog interface to use the powerbox.

The security of the powerbox relies on it having a secure path to the
user, such that the user can enter a filename into the dialog box but
the application cannot.  This of course falls down because X doesn't
yet provide any security at this level.

Here's what I want to do:

Initially I want to run an X client totally confined, so that it
cannot interact with other X clients at all.  It would only be able to
refer to X resources that it created itself, with the exception of
being able to map top-level windows inside the root window.  There
would need to be a limit on setting properties on top-level windows,
so that we can ensure that window titles contain the application's
name.

For the purposes of Plash, setting up an X connection securely is the
simple part.  Plash controls access to Unix domain sockets, so when an
app opens /tmp/.X11-unix/X0, it's possible to hand it a file
descriptor for an X connection that has been suitably restricted.  (In
this context, X's Xauthority mechanism isn't really needed.)  The
question is, how would I create an X connection that has been
restricted?  I can write an X proxy, but of course that will hurt
performance.

In the long term, the hardest aspect of X access control will be to
allow X clients to co-operate securely, such as when one client needs
to open a child window inside another client's window.  To do this
securely would require changing the apps so that one client may grant
another limited access to one of its X resources (such as a window).

I'd be interested to see how this overlaps with the XACE and XSELinux
changes.

Mark