Proposal: Generalized Security Framework for X server

Proposal: Generalized Security Framework for X Server
Date: 3 March 2004

Author: Eamon Walsh <[email protected]>
Organization: NSA SELinux Team


Summary

In the Linux kernel, the Linux Security Module [3] provides the
ability to implement arbitrary kernel security extensions.  LSM does
this by providing hook functions which can be used to arbitrate access
at key points in the kernel.  LSM also provides space to store
security labels which are associated with kernel objects.

We've been working on a similar type of thing for the X Server,
implemented as an extension.  It is based on the current "Security"
extension [1].  The remainder of this paper describes how it works.
It is a general security framework, which could be used to make
extensions that do:

- What the original Security extension does
- Auditing
- Multi-level security (MLS)
- Jail-style restrictions (clients can see some resources, but not others)
- Trusted window labeling (requires trusted window manager)
- SELinux (type enforcement and role-based access control) support for X [2]

The extension is called the "X Security Module" right now but this
could be changed (there is also an "X Session Manager" which could
create confusion).

We are interested in having an X Server development project host this
work on an experimental basis, in the hope that it gains use as the
preferred X Server for use on trusted platforms (such as SELinux
kernel-based Linux distributions).


How It Works

The X server already has most of what is needed.  The Security
extension has code at key points in the dix and os layers.  It also
has fields in the Client and ExtensionEntry structures where it stores
some state (an authId, a trustLevel, and a callback function pointer
in the case of the client).

The X server also has a resource manager that assigns a resource ID to
most server objects.  The resource ID allows you to determine which
client owns the resource.  The current Security extension controls
access to resources (using its simple two-level trust model) via a
callback function that gets called on each resource access.

Basically, the X Security Framework replaces the simple two-level
trust model of the Security extension with a more general facility
that can be used by other extensions which provide their own callback
functions and security state (labeling).


Security State

The Security extension has these fields in the client structure:

#ifdef XCSECURITY
    XID         authId;
    unsigned int trustLevel;
    pointer (* CheckAccess)(
            ClientPtr /*pClient*/,
            XID /*id*/,
            RESTYPE /*classes*/,
            Mask /*access_mode*/,
            pointer /*resourceval*/
    );
#endif

The XSM replaces these with more general state pointers:

#ifdef XSM
    pointer securityState[NUM_SLOTS];
#endif

Extensions can register themselves at init time via a call to
XSMRegisterExtension(), which returns an index number into the
securityState array.  The extension can then allocate some memory and
store whatever it wants there, freeing the memory using a
ClientStateCallback when the client exits.  (The number of extensions
that can store security state is limited by the value of NUM_SLOTS).

The same type of securityState array replaces the "Bool secure" field
in the ExtensionEntry structure.  Extensions can use the same index
number and initialize the security state through a generalized
DeclareExtensionSecurity() callback.  This part of XSM is still under
development though; the DeclareExtensionSecure() call still only takes
a boolean secure/insecure value, and not all extensions call this
function.


Security Callbacks

Wherever the Security extension has code in the dix and os layers that
does a check, we can instead have code that simply marshals arguments
and calls a CallbackList.  For example, in ProcQueryExtension()
(dix/extension.c) right now we have:

        i = FindExtension((char *)&stuff[1], stuff->nbytes);
        if (i < 0
#ifdef XCSECURITY
            /* don't show insecure extensions to untrusted clients */
            || (client->trustLevel == XSecurityClientUntrusted &&
                !extensions[i]->secure)
#endif
            )
            reply.present = xFalse;
        else
        {
            reply.present = xTrue;
	    ...


XSM replaces this with:


        i = FindExtension((char *)&stuff[1], stuff->nbytes);
        if (i < 0
#ifdef XSM
            /* call callbacks to find out whether to show extension */
            || !XSMHook(XSM_EXT_ACCESS, client, extensions[i])
#endif
            )
            reply.present = xFalse;
        else
        {
            reply.present = xTrue;
	    ...

The first argument to SecmodHook() is the type of security event.  XSM
maintains a CallbackList for each event type.  The remaining arguments
are marshalled into a structure along with a return value field that
is the return value of SecmodHook().  This structure gets passed to
the callback functions.

XSM provides a RegisterCallback() function that extensions can use to
add a callback function for a given event.  Each callback function can
examine the fields of the structure and set the result field based on
whether or not it wishes to allow access.  Where there are multiple
callbacks, each callback is supposed to honor the decisions of the
others (i.e. not set the return value to TRUE if it was previously
changed to FALSE by someone else).

Note that the callback function can make its decision based on the
security state it has stored in the Client and ExtensionEntry
structures.

Here is a description of all the security hooks currently in XSM.
Adding another one is a matter of adding another symbolic constant and
structure to XSM and placing a call to XSMHook() at the appropriate
place in the server code.

XSM_RESOURCE_ACCESS
	Arguments: client, resourceID, resourceType, accessMode, resourcePtr
	Arbitrates access to resources.
XSM_DEVICE_ACCESS
	Arguments: client, devicePtr, bool fromRequest
	Arbitrates access to devices.
XSM_PROPERTY_ACCESS
	Arguments: client, window, propertyName, accessMode
	Arbitrates access to properties.
XSM_DRAWABLE_ACCESS
	Arguments: client, drawablePtr
	Arbitrates access to drawable contents.
XSM_MAP_ACCESS
	Arguments: client, windowPtr
	Arbitrates ability to map windows.
XSM_BACKGRND_ACCESS
	Arguments: client, windowPtr
	Arbitrates ability to create background-None windows
XSM_EXT_ACCESS
	Arguments: client, extensionEntry
	Arbitrates access to server extensions
XSM_HOST_ACCESS
	Arguments: client
	Arbitrates ability to change host access list
XSM_SITE_POLICY
	Arguments: char *policyString
	Facility for indicating support of a certain site policy
XSM_DECLARE_EXT_SECURE
	Arguments: extensionEntry, bool secureflag
	Facility for extensions to indicate their secureness.
XSM_AUTH_AVAIL
	Arguments: client, authId
	Additional ClientStateCallback when the authId becomes available.

XSM_LBX_EXT_ACCESS
	Arguments: client, lbxExtensionEntry
	EXT_ACCESS equivalent for LBX
XSM_DECLARE_LBX_EXT_SECURE
	Arguments: lbxExtensionEntry, bool secureflag
	DECLARE_EXT_SECURE equivalent for LBX
XSM_LBX_PROXY_ACCESS
	Arguments: client, authID
	Checks the authorization of a client connecting through a LBX proxy.


Extension Files

In addition to the code in the dix and os layers which replaces the
XCSECURITY code, XSM has the usual extension files xsm.c xsm.h and
xsmstr.h which provide the interface used by other extensions.  It
does not currently have any client requests, events, or errors defined
(i.e. no changes to Xlib.)  It might be necessary to have at least the
standard QueryVersion request, however.


References

[1] David Wiggins, "Security Extension Specification."
www.xfree86.org/~herrb/security.pdf

[2] SELinux papers:  http://www.nsa.gov/selinux/docs.cfm

[3] Linux Security Module:  http://lsm.immunix.org