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

[Mark Seaborn]

Bryan Ericson <bericson at TrustedCS.com> wrote:

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

I saw that the page <http://wiki.x.org/wiki/ChangesForX11R71> says
that including XACE and XSELinux is planned for the 7.1 release.  Is
that still the case?

Have XACE and XSELinux been included in the X servers of Linux
distributions that incorporate SELinux?

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

For a security extension to plug in to XACE, is this going to require
rebuilding the whole X server?  If a security extension is loadable as
a separate *.o module, presumably it would be specific to a particular
version of the X server?

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

Do XACE and XSELinux provide any new X requests?

How do X connections get set up with XSELinux?  More specifically, how
does the X server come to associate a connection with a specific
identity/principal/security context?  Is it just a matter of calling
an SELinux-specific syscall on the socket file descriptor to find out
what it is connected to?

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

I'm curious, do the SELinux folks see this as a drawback of SELinux?

Cheers,
Mark