You are here SELinux / Example: Cross Domain using Type Enforcement

Example: Cross Domain using Type Enforcement

This example demonstrates the basic capabilities of the SELinux Type Enforcement (TE) policy in a Cross Domain environment. Two fundamental Type Enforcement capabilities are demonstrated:

  1. The ability to calculate a database object’s context  (i.e., its Type) based upon the domain that creates the object (e.g., US Domain) and the container of the created object (e.g., a table is a container of a row).

  2. The ability to permit or deny SQL operations upon an object (e.g., row) based upon the operation (e.g., SELECT, UPDATE), the domain that requests the operation, and the object’s context (e.g., the row’s Type).

These TE capabilities are configured using a simple scripting language and may be customized for a particular environment.


Note that these TE capabilities are not possible using the more static Multilevel Security (MLS) policy model. The MLS model predetermines an object’s creation label to be equal to the label of the creating subject. Therefore, with MLS, a subject may only create objects with a single label while Type Enforcement allows objects with any number of unique contexts to be created. Because the creation contexts are used for access control, the plurality of object contexts allow very flexible access control decisions. Additionally, MLS predetermines the behavior between objects and subjects based upon their labels (i.e., write objects with equal labels and read objects with less than or equal labels). With TE an Access Control List (ACL) approach is taken where the security behavior of each SQL operations (e.g., SELECT, UPDATE) is defined using the scripting language.


The security requirements of the example and related SELinux script rules are:

  • A single cross domain table named FlightArrivals containing one row for each arrival of an aircraft at a US airbase. Each row will have the aircraft type and the flight’s origin.
    • The table has a Type of usarrivals_t.
  • Three security domains: United States (US), United Kingdom (UK), and France (FR). Flights only arrive from the US and UK. France will only be able to observe flight arrivals originating from the UK.
    • Trusted RUBIX RDBMS session will be labeled usdom_t, ukdom_t, or frdom_t if the session originates from the US Domain, UK Domain, or FR Domain, respectively.
  • The US and UK Domains may insert rows into the table representing flights originating from their respective countries. As rows are inserted they are automatically labeled with a Type identifying the domain (usflt_t and ukflt_t). The France Domain is not permitted to insert rows. The following SELinux type_transition rules cause the rows to automatically be labeled with the appropriate Type.
    • type_transition usdom_t usarrivals_t : db_tuple usflt_t
    • type_transition ukdom_t usarrivals_t : db_tuple ukflt_t
  • The US Domain may select all rows. The UK and FR Domains may only select rows representing flights from the UK (i.e., rows with the ukflt_t Type).
    • allow usdom_t usflt_t : db_tuple select
    • allow usdom_t ukflt_t : db_tuple select
    • allow ukdom_t ukflt_t : db_tuple select
    • allow frdom_t ukflt_t : db_tuple select
  • The US and UK domain may only update rows which were inserted from their respective domain (usflt_t and ukflt_t Types respectively). The France domain is not permitted to update rows.
    • allow usdom_t usflt_t : db_tuple update
    • allow ukdom_t ukflt_t : db_tuple update
  • The US domain may delete any row as the corresponding flights terminate. The UK and France domains are not permitted to delete rows.
    • allow usdom_t usflt_t : db_tuple delete
    • allow usdom_t ukflt_t : db_tuple delete

The following diagram shows the architecture and SQL operation behavior.