Difference between revisions of "NB XWIN"

From SELinux Wiki
Jump to: navigation, search
Line 277: Line 277:

Revision as of 21:06, 13 September 2010

SELinux X-Windows Support

The SELinux X-Windows (XSELinux) implementation provides fine grained access control over the majority of the X-server objects (known as resources). The Reference Policy modules have also been updated to enforce policy using the XSELinux object manager (OM).

This section will only give a high level description of the infrastructure based on the X-Server and XSELinux Object Manager diagram, however the "Application of the Flask Architecture to the X Window System Server" paper has a good overview of how the object manager (OM) has been implemented, although it does not cover areas such as polyinstantiation. There are also some sample X-widows applications for experimenting with policy in the Experimenting with X-Windows section of volume 2 (and also in the Experimenters Corner section).

The object classes and permissions are listed in the X Windows Object Classes section.

Infrastructure Overview

It is important to note that the X-windows OM operates on the low level window objects of the X-server. A windows manager (such as Gnome or twm) would then sit above this, however they (the windows manager or even the lower level Xlib) would not be aware of the policy being enforced by SELinux. Therefore there can be situations where X-windows applications get bitter & twisted at the denial of a service. This can result in either opening the policy more than desired, just letting the application keep aborting, or modifying the application.

Using the X-Server and XSELinux Object Manager diagram, the major components that form the overall XSELinux OM are (top left to right):

The Policy - The Reference Policy has been updated to support the XSELinux OM and F-12 is now operational from policy version selinux-policy-3.6.32-100.fc12 for targeted and mls versions (Note that in F-12 the OM is enabled for mls and disabled for targeted policies via the xserver-object-manager boolean).
libselinux - This library provides the necessary interfaces between the OM , the SELinux userspace services (e.g. reading configuration information and providing the AVC), and kernel services (e.g. security server for access decisions and policy update notification).
x_contexts File - This contains context configuration information that is required by the OM for labeling certain objects. The OM reads its contents using the selabel_lookup function.
XSELinux Object Manager - This is an X-extension for the X-server process that mediates all access decisions between the the X-server (via the XACE interface) and the SELinux security server (via libselinux). The OM is initialised before any X-clients connect to the X-server.
The OM has added X-protocol extensions to allow contexts to be set and retrieved by userspace SELinux-aware applications. These are shown in Table 1 and used in the Experimenting with X-Windows section.
XACE Interface - This is a standards based 'X Access Control Extension' (XACE) that can be used by other access control security extensions, not only SELinux. Note that if other security extensions are linked at the same time, then the X-function will only succeed if allowed by all the security extensions in the chain.
The interface is defined in the "X Access Control Extension Specification". This specification also defines the hooks available to OMs and how they should be used. The provision of polyinstantiation services for properties and selections is also discussed. The XACE interface is a similar service to the LSM that supports the kernel OMs.
X-server - This is the core X-windows server process that handles all request and responses to/from X-clients using the X-protocol. The XSELinux OM is intercepting these request/responses via XACE and enforcing policy decisions.
X-clients - These connect to the X-server are are typically windows managers such as Gnome, twm or KDE. The default for F-12 is the Gnome desktop manager.
Kernel-Space Services - These are discussed in the Linux Security Module and SELinux section.

Function Name Minor Opcode Parameters Comments
None Returns the XSELinux version. F-12 returns 1.0
Context+Len This is used by SELinux-aware applications for setting the context on device data.
None Get the context set on the device data. This is for use by SELinux-aware applications.
DeviceID + Context+Len This is used by SELinux-aware applications for setting the context on selected x_device object.
DeviceID Get context of the selected x_device object.
Context+Len This is used by SELinux-aware applications for setting the context on windows data.
None Get the context set on the window data. This is for use by SELinux-aware applications.
WindowID Get the process context that this window is running under (x_drawable object ??)
Context+Len This is used by SELinux-aware applications for setting the context on property data.
None Get the context set on the property data. This is for use by SELinux-aware applications.
Context+Len This is for use by SELinux-aware applications for setting the context on the property object itself.
None Get the property object context. This is for use by SELinux-aware applications.
WindowID + AtomID Get context of the x_property object.
WindowID + AtomID Get the context of the property data. This could be the policy default or that set by the SELinuxSetPropertyCreateContext (9) function.
WindowID List the contexts of properties associated with the selected WindowID.
Context+Len This is used by SELinux-aware applications for setting the context on selected data.
None Get the context set on the selected data. This is for use by SELinux-aware applications.
Context+Len This is for use by SELinux-aware applications for setting the context on the selection object itself.
None Get the selection object context. This is for use by SELinux-aware applications.
AtomID Get context of the x_selection object.
AtomID Get the context of the selected data. This could be the policy default or that set by the SELinuxSetSelectionCreateContext (15) function.
None List the selection atoms for this display. The main difference in the listings is that when the PRIMARY selection atom is polyinstantiated, multiple entries can returned. One has the context of the atom itself, and one entry for each process (or x-client) that has an active polyinstantiated entry, for example:

Atom: PRIMARY - label defined in the x_contexts file (this is also for non-poly listing):

Object Context: system_u:object_r:primary_xselection_t
Data Context:   system_u:object_r:primary_xselection_t

Atom: PRIMARY - Labels for client 1:

Object Context: system_u:object_r:x_select_paste1_t
Data Context:   system_u:object_r:x_select_paste1_t

Atom: PRIMARY - Labels for client 2:

Object Context: system_u:object_r:x_select_paste2_t
Data Context:   system_u:object_r:x_select_paste2_t
ResourceID This function will return the process context any valid X resource ID is running under (or the x_client object ?).

Table 1: The XSELinux Functions - Supported by the object manager as X-protocol extensions. Note that some functions will return the default contexts, while others (2, 6, 9, 11, 16, 18) will not return a value unless one has been set the the appropriate function (1, 5, 8, 10, 15, 17) by an SELinux-aware application.


The OM / XACE services support polyinstantiation of properties and selections as these form the InterClient Communication (ICC) that allows X-clients to communicate and exchange information. This allows properties and selections to be grouped into different membership areas so that one group does not know of the exsistance of the others. To implement polyinstantiation the poly_ keyword is required in the x_contexts file for the required selections and/or properties, there is then a corresponding type_member rule in the policy to enforce the separation.

The Experimenting with X-Windows section in volume 2 has examples of using polyinstantiation for selections and then comparing the results to non-polyinstantiated cases.

Note that the current Reference Policy (build 20091117) does not implement polyinstantiation, instead the MLS policy version uses the mlsconstrain statement to limit the scope of these.

Configuration Information

This section covers:

  • How to determine the OM X-extension opcode.
  • How to configure the OM in permissive mode.
  • How to disable the OM when using the Reference policy.
  • The x-contexts configuration file.
  • The OMs SELinuxGet/Set.. functions (shown in Table 1).

Determine OM X-extension Opcode

The object manager is treated as an X-server extension and its major opcode can be queried using Xlib XQueryExtension function as follows:

// Get the SELinux Extension opcode
if (!XQueryExtension (dpy, "SELinux", &opcode, &event, &error)) {
perror ("XSELinux extension not available");
exit (1);
printf ("XQueryExtension for XSELinux Extension - Opcode: %d 
Events: %d Error: %d \n", opcode, event, error);
// Have XSELinux Object Manager

Configure OM in Permissive Mode

If the X-server object manager needs to be run in permissive mode the following entry can be added to the xorg.conf file (normally in /etc):

Section "Module"
SubSection "extmod"
Option "SELinux mode permissive"

=== Disable the OM ===
The Reference Policy has a boolean that can be used to disable the x-server object manager if is not required by:
setsebool -P xserver_object_manager false 

The x_contexts File

The x_contexts file contains labels and initial context information that is required by the OM to initialise the service and then to label objects as they are created. The policy will also need to be aware of the context information being used as it will use this to enforce policy or transition to a new context. A typical entry is as follows:

# object_type object_name context
selection PRIMARY system_u:object_r:clipboard_xselection_t

or for polyinstantiation support:

# object_type object_name context
poly_selection PRIMARY system_u:object_r:clipboard_xselection_t

The object_name can contain '*' for 'any' or '?' for 'substitute'.

The OM uses the selabel functions (such as selabel_lookup) that are a part of libselinux (see the libselinux API section) to fetch the relevant information from the x_contexts file.

The valid object_type entries are client, property, poly_property, extension, selection, poly_selection and events.

The object_name entries can be any valid X-server resource name that is defined in the X-server source code and can typically be found in the protocol.txt and BuiltInAtoms source files (in the dix directory of the xorg-server source package), or user generated via the Xlib libraries (e.g. XInternAtom). Note that if an object_name has both poly and non-poly entries in the file, the non-poly entry takes precedence (i.e. the poly entry is ignored by the OM).

Note that for systems using the Reference Policy all X-clients connecting remotely will be allocated a security context from the x_contexts file of:

# object_type object_name context
client * system_u:object_r:remote_t

Experimenters Corner section has examples of adding additional entries to the x_contexts file.

A full description of the x_contexts file format is given in the contexts/x_contexts File section.