Difference between revisions of "NB XWIN"
Line 1: | Line 1: | ||
− | = | + | = 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) | + | 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 "<tt>SELinux</tt>". |
− | This | + | This Notebook will only give a high level description of the infrastructure based on the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/23-x-server.png X-Server and XSELinux Object Manager X-Server and XSELinux Object Manager] diagram, however the "[http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf Application of the Flask Architecture to the X Window ][http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf 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 object classes and permissions are listed in the [[ | + | The X-Windows object classes and permissions are listed in the [[NB_ObjectClassesPermissions#X Windows Object Classes | 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 [[NB_SandBox | Sandbox Services]] section for details. | ||
== Infrastructure Overview == | == Infrastructure Overview == | ||
− | It is important to note that the X- | + | 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 [http://taiga.selinuxproject.org/~rhaines/diagrams/ | + | Using the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/23-x-server.png 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 <tt>xserver-object-manager</tt> boolean. Enabling this boolean also initialises the XSELinux OM extension. Important note - The boolean must be present in any policy and be set to <tt>true</tt>, otherwise the object manager will be disabled as the code specifically checks for the boolean. | ||
+ | : <tt>'''libselinux'''</tt> - 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). | ||
+ | : <tt>'''x_contexts</tt> File''' - This contains default context configuration information that is required by the OM for labeling certain objects. The OM reads its contents using the <tt>'''selabel_lookup'''(3)</tt> 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 <tt>libselinux</tt>). The OM is initialised before any X-clients connect to the X-server. The OM has also added XSELinux functions that are described in [[#SELinux_Extension_Functions | 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 "[http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.pdf 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 [[NB_LSM | Linux Security Module and SELinux]] section. | ||
− | + | ==== 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 <tt>poly_</tt> keyword is used in the <tt>x_contexts</tt> file for the required selections and properties, there would then be a corresponding <tt>type_member</tt> statement in the policy to enforce the separation by computing a new context with either <tt>'''security_compute_member'''(3)</tt> or <tt>'''avc_compute_member'''(3)</tt>. | ||
− | + | Note that the current Reference Policy does not implement polyinstantiation, instead the MLS policy uses <tt>mlsconstrain</tt> rules to limit the scope of properties and selections. | |
− | : | + | == 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 <tt>x-contexts</tt> configuration file. | ||
− | + | === Enable/Disable the OM from Policy Decisions === | |
+ | The Reference Policy has a <tt>xserver_object_manager</tt> 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 <tt>init 3</tt> and then <tt>init 5</tt> commands): | ||
+ | <pre> | ||
+ | setsebool -P xserver_object_manager true | ||
+ | </pre> | ||
+ | If the boolean is set to <tt>false</tt>, 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 <tt>xorg.conf</tt> file as described in the [[#Configure OM Enforcement Mode | Configure OM Enforcement Mode]] section). | ||
− | + | === Determine OM X-extension Opcode === | |
+ | The object manager is treated as an X-server extension and its major opcode can be queried using Xlib <tt>XQueryExtension</tt> function as follows: | ||
+ | <pre> | ||
+ | /* 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 | ||
+ | </pre> | ||
− | + | If there is no entry, the object manager will follow the current SELinux enforcement mode. | |
− | + | === The x_contexts File === | |
+ | The <tt>x_contexts</tt> 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: | ||
+ | <pre> | ||
+ | # object_type object_name context | ||
+ | selection PRIMARY system_u:object_r:clipboard_xselection_t:s0 | ||
+ | </pre> | ||
+ | or for polyinstantiation support: | ||
+ | <pre> | ||
+ | # object_type object_name context | ||
+ | poly_selection PRIMARY system_u:object_r:clipboard_xselection_t:s0 | ||
+ | </pre> | ||
− | + | The <tt>object_name</tt> can contain '<tt><nowiki>*</nowiki></tt>' for 'any' or '<tt>?</tt>' for 'substitute'. | |
+ | The OM uses the <tt>selabel</tt> functions (such as <tt>'''selabel_lookup'''(3)</tt>) that are a part of <tt>libselinux</tt> to fetch the relevant information from the<tt> x_contexts</tt> file. | ||
+ | The valid <tt>object_type</tt> entries are <tt>client</tt>, <tt>property</tt>, <tt>poly_property</tt>, <tt>extension</tt>, <tt>selection</tt>, <tt>poly_selection</tt> and <tt>events</tt>. | ||
+ | |||
+ | The <tt>object_name</tt> 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 <tt>protocol.txt</tt> and <tt>BuiltInAtoms</tt> source files (in the <tt>dix</tt> directory of the <tt>xorg-server</tt> source package), or user generated via the Xlib libraries (e.g. <tt>XInternAtom</tt>). | ||
+ | |||
+ | Notes: | ||
+ | * The way the XSELinux extension code works (see <tt>xselinux_label.c</tt> - <tt>SELinuxAtomToSIDLookup</tt>) 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 '<tt>poly_selection *</tt>' or '<tt>poly_property *</tt>' 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 <tt>x_contexts</tt> file of: | ||
+ | <pre> | ||
+ | # object_type object_name context | ||
+ | client * system_u:object_r:remote_t:s0 | ||
+ | </pre> | ||
+ | : A full description of the <tt>x_contexts</tt> file format is given in the [[PolicyConfigurationFiles#contexts/x_contexts File | x_contexts File]] section. | ||
+ | |||
+ | |||
+ | == SELinux Extension Functions == | ||
+ | <center>'''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.''</center> | ||
{| border="1" | {| border="1" | ||
− | + | ! Function Name | |
− | + | ! Minor Opcode | |
− | + | ! Parameters | |
− | + | ! Comments | |
|- | |- | ||
− | | | + | | XSELinuxQueryVersion |
| <center>0</center> | | <center>0</center> | ||
| None | | None | ||
− | | Returns the XSELinux version. F- | + | | Returns the XSELinux version. F-20 returns 1.1 |
|- | |- | ||
− | | | + | | XSELinuxSetDeviceCreateContext |
| <center>1</center> | | <center>1</center> | ||
| Context+Len | | Context+Len | ||
− | | | + | | Sets the context for creating a device object (<tt>x_device</tt>). |
|- | |- | ||
− | | | + | | XSELinuxGetDeviceCreateContext |
| <center>2</center> | | <center>2</center> | ||
| None | | None | ||
− | | | + | | Retrieves the context set by <tt>XSELinuxSetDeviceCreateContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxSetDeviceContext |
| <center>3</center> | | <center>3</center> | ||
| DeviceID + Context+Len | | DeviceID + Context+Len | ||
− | | | + | | Sets the context for creating the specified DeviceID object. |
|- | |- | ||
− | | | + | | XSELinuxGetDeviceContext |
| <center>4</center> | | <center>4</center> | ||
| DeviceID | | DeviceID | ||
− | | | + | | Retrieves the context set by <tt>XSELinuxSetDeviceContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxSetWindowCreateContext |
| <center>5</center> | | <center>5</center> | ||
| Context+Len | | Context+Len | ||
− | | | + | | Set the context for creating a window object (<tt>x_window</tt>). |
|- | |- | ||
− | | | + | | XSELinuxGetWindowCreateContext |
| <center>6</center> | | <center>6</center> | ||
| None | | None | ||
− | | | + | | Retrieves the context set by <tt>XSELinuxSetWindowCreateContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxGetWindowContext |
| <center>7</center> | | <center>7</center> | ||
| WindowID | | WindowID | ||
− | | | + | | Retrieves the specified WindowID context. |
|- | |- | ||
− | | | + | | XSELinuxSetPropertyCreateContext |
| <center>8</center> | | <center>8</center> | ||
− | | Context+Len | + | | Context + Len |
− | | | + | | Sets the context for creating a property object (<tt>x_property</tt>). |
|- | |- | ||
− | | | + | | XSELinuxGetPropertyCreateContext |
| <center>9</center> | | <center>9</center> | ||
| None | | None | ||
− | | | + | | Retrieves the context set by <tt>XSELinuxSetPropertyCreateContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxSetPropertyUseContext |
| <center>10</center> | | <center>10</center> | ||
− | | Context+Len | + | | Context + Len |
− | | | + | | Sets the context of the property object to be retrieved when polyinstantiation is being used. |
|- | |- | ||
− | | | + | | XSELinuxGetPropertyUseContext |
| <center>11</center> | | <center>11</center> | ||
| None | | None | ||
− | | | + | | Retrieves the property object context set by <tt>SELinuxSetPropertyUseContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxGetPropertyContext |
| <center>12</center> | | <center>12</center> | ||
| WindowID + AtomID | | WindowID + AtomID | ||
− | | | + | | Retrieves the context of the property atom object. |
|- | |- | ||
− | | | + | | XSELinuxGetPropertyDataContext |
| <center>13</center> | | <center>13</center> | ||
| WindowID + AtomID | | WindowID + AtomID | ||
− | | | + | | Retrieves the context of the property atom data. |
|- | |- | ||
− | | | + | | XSELinuxListProperties |
| <center>14</center> | | <center>14</center> | ||
| WindowID | | WindowID | ||
− | | | + | | Lists the object and data contexts of properties associated with the selected WindowID. |
|- | |- | ||
− | | | + | | XSELinuxSetSelectionCreateContext |
| <center>15</center> | | <center>15</center> | ||
| Context+Len | | Context+Len | ||
− | | | + | | Sets the context to be used for creating a selection object. |
|- | |- | ||
− | | | + | | XSELinuxGetSelectionCreateContext |
| <center>16</center> | | <center>16</center> | ||
| None | | None | ||
− | | | + | | Retrieves the context set by <tt>SELinuxSetSelectionCreateContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxSetSelectionUseContext |
| <center>17</center> | | <center>17</center> | ||
| Context+Len | | Context+Len | ||
− | | | + | | Sets the context of the selection object to be retrieved when polyinstantiation is being used. See the <tt>XSELinuxListSelections</tt> function for an example. |
|- | |- | ||
− | | | + | | XSELinuxGetSelectionUseContext |
| <center>18</center> | | <center>18</center> | ||
| None | | None | ||
− | | | + | | Retrieves the selection object context set by <tt>SELinuxSetSelectionUseContext</tt>. |
|- | |- | ||
− | | | + | | XSELinuxGetSelectionContext |
| <center>19</center> | | <center>19</center> | ||
| AtomID | | AtomID | ||
− | | | + | | Retrieves the context of the specified selection atom object. |
|- | |- | ||
− | | | + | | XSELinuxGetSelectionDataContext |
| <center>20</center> | | <center>20</center> | ||
| AtomID | | AtomID | ||
− | | | + | | Retrieves the context of the selection data from the current selection owner (<tt>x_application_data</tt> object). |
|- | |- | ||
− | | | + | | XSELinuxListSelections |
| <center>21</center> | | <center>21</center> | ||
| None | | 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 <tt>PRIMARY</tt> 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<tt> x_contexts</tt> file (this is also for non-poly listing): | Atom: PRIMARY - label defined in the<tt> x_contexts</tt> file (this is also for non-poly listing): | ||
Object Context: system_u:object_r:primary_xselection_t | Object Context: system_u:object_r:primary_xselection_t | ||
+ | |||
Data Context: system_u:object_r:primary_xselection_t | Data Context: system_u:object_r:primary_xselection_t | ||
+ | |||
Atom: PRIMARY - Labels for client 1: | Atom: PRIMARY - Labels for client 1: | ||
Object Context: system_u:object_r:x_select_paste1_t | Object Context: system_u:object_r:x_select_paste1_t | ||
+ | |||
Data 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: | Atom: PRIMARY - Labels for client 2: | ||
Object Context: system_u:object_r:x_select_paste2_t | Object Context: system_u:object_r:x_select_paste2_t | ||
+ | |||
Data Context: system_u:object_r:x_select_paste2_t | Data Context: system_u:object_r:x_select_paste2_t | ||
|- | |- | ||
− | | | + | | XSELinuxGetClientContext |
| <center>22</center> | | <center>22</center> | ||
| ResourceID | | ResourceID | ||
− | | | + | | Retrieves the client context of the specified ResourceID. |
|} | |} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | {| style="width: 100%;" border="0" | ||
+ | |- | ||
+ | | [[NB_PAM | '''Previous''']] | ||
+ | | <center>[[NB_SandBox | '''Home''']]</center> | ||
+ | | <center>[[NB_SQL_9.3 | '''Next''']]</center> | ||
+ | |} | ||
Revision as of 12:14, 8 December 2014
Contents
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.
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.
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.
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.
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).
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.
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.
SELinux Extension Functions
Function Name | Minor Opcode | Parameters | Comments |
---|---|---|---|
XSELinuxQueryVersion | |
None | Returns the XSELinux version. F-20 returns 1.1 |
XSELinuxSetDeviceCreateContext | |
Context+Len | Sets the context for creating a device object (x_device). |
XSELinuxGetDeviceCreateContext | |
None | Retrieves the context set by XSELinuxSetDeviceCreateContext. |
XSELinuxSetDeviceContext | |
DeviceID + Context+Len | Sets the context for creating the specified DeviceID object. |
XSELinuxGetDeviceContext | |
DeviceID | Retrieves the context set by XSELinuxSetDeviceContext. |
XSELinuxSetWindowCreateContext | |
Context+Len | Set the context for creating a window object (x_window). |
XSELinuxGetWindowCreateContext | |
None | Retrieves the context set by XSELinuxSetWindowCreateContext. |
XSELinuxGetWindowContext | |
WindowID | Retrieves the specified WindowID context. |
XSELinuxSetPropertyCreateContext | |
Context + Len | Sets the context for creating a property object (x_property). |
XSELinuxGetPropertyCreateContext | |
None | Retrieves the context set by XSELinuxSetPropertyCreateContext. |
XSELinuxSetPropertyUseContext | |
Context + Len | Sets the context of the property object to be retrieved when polyinstantiation is being used. |
XSELinuxGetPropertyUseContext | |
None | Retrieves the property object context set by SELinuxSetPropertyUseContext. |
XSELinuxGetPropertyContext | |
WindowID + AtomID | Retrieves the context of the property atom object. |
XSELinuxGetPropertyDataContext | |
WindowID + AtomID | Retrieves the context of the property atom data. |
XSELinuxListProperties | |
WindowID | Lists the object and data contexts of properties associated with the selected WindowID. |
XSELinuxSetSelectionCreateContext | |
Context+Len | Sets the context to be used for creating a selection object. |
XSELinuxGetSelectionCreateContext | |
None | Retrieves the context set by SELinuxSetSelectionCreateContext. |
XSELinuxSetSelectionUseContext | |
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 | |
None | Retrieves the selection object context set by SELinuxSetSelectionUseContext. |
XSELinuxGetSelectionContext | |
AtomID | Retrieves the context of the specified selection atom object. |
XSELinuxGetSelectionDataContext | |
AtomID | Retrieves the context of the selection data from the current selection owner (x_application_data object). |
XSELinuxListSelections | |
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:
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 | |
ResourceID | Retrieves the client context of the specified ResourceID. |
Previous | |
|