NB XWIN

From SELinux Wiki

Jump to: navigation, search

Contents

[edit] X-Windows SELinux Support

The SELinux X-Windows (XSELinux) implementation provides fine grained access control over the majority of the X-server objects (known as resources) using an X-Windows extention acting as the object manager (OM). The extension name is "SELinux".

This Notebook will only give a high level description of the infrastructure based on the X-Server and XSELinux Object Manager 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 has been implemented, although it does not cover areas such as polyinstantiation.

The X-Windows object classes and permissions are listed in the X Windows Object Classes section and the Reference Policy modules have been updated to enforce policy using the XSELinux object manager.

On Fedora XSELinux is disabled in the targeted policy but enabled on the MLS policy. This is because Red Hat prefers to use sandboxing with the Xephyr server to isolate windows with the targeted policy, see the Sandbox Services section for details.

[edit] 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, or just letting the application keep aborting, or modifying the application.

Using the X-Server and XSELinux Object Manager 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, however in Fedora the OM is enabled for mls and disabled for targeted policies via the xserver-object-manager boolean. Enabling this boolean also initialises the XSELinux OM extension. Important note - The boolean must be present in any policy and be set to true, otherwise the object manager will be disabled as the code specifically checks for the 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 default context configuration information that is required by the OM for labeling certain objects. The OM reads its contents using the selabel_lookup(3) 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 also added XSELinux functions that are described in Table 1 to allow contexts to be retrieved and set by userspace SELinux-aware applications.
XACE Interface - This is an '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. This interface is defined in the "X Access Control Extension Specification. The 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.
Kernel-Space Services - These are discussed in the Linux Security Module and SELinux section.

[edit] Polyinstantiation

The OM / XACE services support polyinstantiation of properties and selections allowing these 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 used in the x_contexts file for the required selections and properties, there would then be a corresponding type_member statement in the policy to enforce the separation by computing a new context with either security_compute_member(3) or avc_compute_member(3).

Note that the current Reference Policy does not implement polyinstantiation, instead the MLS policy uses mlsconstrain rules to limit the scope of properties and selections.

[edit] Configuration Information

This section covers:

  • How to enable/disable the OM X-extension.
  • How to determine the OM X-extension opcode.
  • How to configure the OM in a specific SELinux enforcement mode.
  • The x-contexts configuration file.

[edit] Enable/Disable the OM from Policy Decisions

The Reference Policy has a xserver_object_manager boolean that enables/disables the X-server policy module and also stops the object manager extension from initialising when X-Windows is started. The following command will enable the boolean, however it will be necessary to reload X-Windows to initialise the extension (i.e. run the init 3 and then init 5 commands):

setsebool -P xserver_object_manager true

If the boolean is set to false, the x-server log will indicate that "SELinux: Disabled by boolean". Important note - If the boolean is not present in a policy then the object manager will always be enabled (therefore if not required then either do not include the object manager in the X-server build, add the boolean to the policy and set it to false or add a disabled entry to the xorg.conf file as described in the Configure OM Enforcement Mode section).

[edit] 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);
} else {
    printf ("XQueryExtension for XSELinux Extension - Opcode: %d 
                Events: %d Error: %d \n", opcode, event, error);
}
<pre>

=== Configure OM Enforcement Mode ===
If the X-server object manager needs to be run in a specific SELinux enforcement mode, then the option may be added to the <tt>xorg.conf</tt> file (normally in <tt>/etc/X11/xorg.conf.d</tt>). The option entries are as follows:
: "SELinux mode disabled"
: "SELinux mode permissive"
: "SELinux mode enforcing"

Note that the entry must be exact otherwise it will be ignored. An example entry is:
<pre>
Section "Module"
    SubSection "extmod"
        Option "SELinux mode enforcing"
    EndSubSection
EndSection

If there is no entry, the object manager will follow the current SELinux enforcement mode.

[edit] The x_contexts File

The x_contexts file contains default context information that is required by the OM to initialise the service and then 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 new objects. A typical entry is as follows:

# object_type   object_name    context
selection       PRIMARY        system_u:object_r:clipboard_xselection_t:s0

or for polyinstantiation support:

# object_type  object_name     context
poly_selection PRIMARY         system_u:object_r:clipboard_xselection_t:s0

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

The OM uses the selabel functions (such as selabel_lookup(3)) that are a part of libselinux 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).

Notes:

  • The way the XSELinux extension code works (see xselinux_label.c - SELinuxAtomToSIDLookup) is that non-poly entries are searched for first, if an entry is not found then it searches for a matching poly entry.
The reason for this behavior is that when operating in a secure environment all objects would be polyinstantiated unless there are specific exemptions made for individual objects to make them non-polyinstantiated. There would then be a 'poly_selection *' or 'poly_property *' at the end of the section.
  • 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:s0
A full description of the x_contexts file format is given in the x_contexts File section.


[edit] SELinux Extension Functions

Table 1: The XSELinux Extension 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.
Function Name Minor Opcode Parameters Comments
XSELinuxQueryVersion
0
None Returns the XSELinux version. F-20 returns 1.1
XSELinuxSetDeviceCreateContext
1
Context+Len Sets the context for creating a device object (x_device).
XSELinuxGetDeviceCreateContext
2
None Retrieves the context set by XSELinuxSetDeviceCreateContext.
XSELinuxSetDeviceContext
3
DeviceID + Context+Len Sets the context for creating the specified DeviceID object.
XSELinuxGetDeviceContext
4
DeviceID Retrieves the context set by XSELinuxSetDeviceContext.
XSELinuxSetWindowCreateContext
5
Context+Len Set the context for creating a window object (x_window).
XSELinuxGetWindowCreateContext
6
None Retrieves the context set by XSELinuxSetWindowCreateContext.
XSELinuxGetWindowContext
7
WindowID Retrieves the specified WindowID context.
XSELinuxSetPropertyCreateContext
8
Context + Len Sets the context for creating a property object (x_property).
XSELinuxGetPropertyCreateContext
9
None Retrieves the context set by XSELinuxSetPropertyCreateContext.
XSELinuxSetPropertyUseContext
10
Context + Len Sets the context of the property object to be retrieved when polyinstantiation is being used.
XSELinuxGetPropertyUseContext
11
None Retrieves the property object context set by SELinuxSetPropertyUseContext.
XSELinuxGetPropertyContext
12
WindowID + AtomID Retrieves the context of the property atom object.
XSELinuxGetPropertyDataContext
13
WindowID + AtomID Retrieves the context of the property atom data.
XSELinuxListProperties
14
WindowID Lists the object and data contexts of properties associated with the selected WindowID.
XSELinuxSetSelectionCreateContext
15
Context+Len Sets the context to be used for creating a selection object.
XSELinuxGetSelectionCreateContext
16
None Retrieves the context set by SELinuxSetSelectionCreateContext.
XSELinuxSetSelectionUseContext
17
Context+Len Sets the context of the selection object to be retrieved when polyinstantiation is being used. See the XSELinuxListSelections function for an example.
XSELinuxGetSelectionUseContext
18
None Retrieves the selection object context set by SELinuxSetSelectionUseContext.
XSELinuxGetSelectionContext
19
AtomID Retrieves the context of the specified selection atom object.
XSELinuxGetSelectionDataContext
20
AtomID Retrieves the context of the selection data from the current selection owner (x_application_data object).
XSELinuxListSelections
21
None Lists the selection atom object and data contexts associated with this display. The main difference in the listings is that when (for example) 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
XSELinuxGetClientContext
22
ResourceID Retrieves the client context of the specified ResourceID.


Previous
Home
Next



    Personal tools