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

[Bryan Ericson]

On Mon, 28 Nov 2005 20:16:18 +0000 (GMT)
Mark Seaborn <mseaborn at onetel.com> wrote:

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

As far as I know.  We're not part of the core group of X maintainers,
so we don't have any control about what goes in, but we're planning on
working hard on it if needed.

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

Not yet, but I think more distros will take a look at them after the
7.0 release. Also, XSELinux provides pretty hard-core security, to the
extent that it will interfere with a normal user's expectations if the
security policy is sufficiently strict, so many of the larger distros
may not be interested.  TCS has been using them internally for months,
however, and we're very happy with their performance.

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

Yes, it will require a rebuild because the initialization functions
for the extensions need to be called from the main server prior to
use. Other than the init functions and slight modifications to
security extensions to utilize XACE as mentioned elsewhere, there are
no modifcations to the source code.  The extensions may be
enabled/disabled in the host's config file if you are building your
own 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?

No, although XSELinux does have a config file that it reads during
initialization in our current implementation.

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

Yup.  Specifically, SELinux has a function called getpeercon() which
retrieves the security context of a peer client.  The XSELinux
extension calls this function to retrieve a context for every X client
that connects to the server.

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

Actually, it's seen as an advantage.  It prevents a malicious program
from attempting to escalate its own privileges.  Also, it allows for
very predictable behavior, which is always a good thing for security. 
I should note that SELinux does have functionality that allows an app
to change its security context dynamically, although this ability is
granted via the security policy only to very carefully written trusted
programs.

Regards,
Bryan