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

[Bryan Ericson]

Hi, Mark

We're continuing to work on XACE and XSELinux here at Trusted Computer
Solutions.  We're released a few patches in the past, and we're
preparing to release some updated patches for Xorg 7 soon after it's
released.  Unfortunately, there was no documentation available for
XACE or XSELinux, and we haven't had time to write any.

XACE (the X Access Control Extension) is a framework into which
security-related extensions can 'plug-in', and XACE will then call
functions in the plugged-in extensions whenever a security decision is
required.  XACE makes no security decisions on its own.

XSELinux is an extension that uses SELinux functionality in the
operating system.  It applies SELinux attributes to various X objects
and then uses those attributes when security decisions are made. 
Strictly speaking, XSELinux does not make security decitions, either -
all the decisions are made by the security policy, which is loaded
into the kernel at startup.

Based on your description, I don't think XSELinux would work for you. 
Access control in SELinux is based on access rules in the security
policy, which cannot be modified on the fly.  Thus, if your app has
access to another app, then it will always have that same level of
access, and a given application has no control over which apps have
access to it.  Note that a new security policy can be loaded which
replaces the existing policy, but this is a very time-consuming
process because the policy much be compiled into a binary object
before being loaded.

Again, we intend to release new XACE and XSELinux patches for Xorg 7
in the near future.  Please let me know if you have any questions.

Thanks,
Bryan Ericson

On Sun, 27 Nov 2005 23:31:22 +0000 (GMT)
Mark Seaborn <mseaborn at onetel.com> wrote:

> 
> 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
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg