You are here SELinux / SELinux Type Enforcement

SELinux Type Enforcement


Type Enforcement (TE) is the SELinux mechanism that actually determines if a particular operation is permitted. In general it takes the subject's type, object's type, object's class, and operation being performed and produces a 'permit' or 'deny' security decision. Text-based policy rules determine which security decision is produced. For example, the following TE rule would allow a subject with the 'rxclient_t' type to perform the 'select' operation on objects of class 'db_tuple' and type 'rxrow_t':

 

    allow rxclient_t rxrow_t : db_tuple select;

 

The following diagram illustrates the TE access checks that occur as two users, Bob and Nancy, perform a 'SELECT * FROM MyTab' query. Bob and Nancy have logged onto the system and set their role appropriately. Note that Bob's context has a type of 'rxclient1_t' and Nancy's context has a type of 'rxclient2_t'. In our example, this will cause each user to receive a different set of rows from their query.

 

The 'MyTab' table is contained within the 'MySchema' schema, which itself is contained within the 'MyCat' catalog. Trusted RUBIX catalogs and schemata are analogous to operating system directories, in that their primary function is to store other objects. In order for the query to execute, the catalog and schema must be searched as follows:

 

Step 1: Search 'MyCat' catalog. The catalog has a type of 'rxcat_t'. Both users are permitted to search the catalog because of the following TE rule:

 

  allow {rxclient1_t rxclient2_t} rxcat_t : dir search;

 

Step 2: Search 'MySchema' schema. The schema has a type of 'rxschem_t'. Both users are permitted to search the schema because of the following TE rule:

 

  allow {rxclient1_t rxclient2_t} rxschem_t : dir search;

 

Next, the 'MyTab' table must be opened and selected from as follows.

 

Step 3: Open/select from 'MyTab' table. The table has a type of 'rxtable_t'. Both users are permitted to perform this operation because of the following TE rule:  

 

  allow {rxclient1_t rxclient2_t} rxtable_t : db_table {use select};

 

Lastly, the query selects individual rows. Unlike the previous operations in this query (e.g., search catalog), where a TE 'deny' security decision would cause the query to fail, a 'deny' on an individual row select causes the row to be filtered from the query's result set. Note that two of the rows have a type of 'rxrow1_t' and two of the rows have a type of 'rxrow2_t'.

 

Step 4a: Bob selects individual rows. The following TE rule allows Bob to select only rows with the 'rxrow1_t' type:

 

  allow rxclient1_t rxrow1_t : db_tuple select;

 

Because no TE rule exist for rows of type 'rxrow2_t', rows with that type are filtered from the result set. Bob's result set consists of 'Rowdata1' and 'Rowdata3'.

 

Step 4b: Nancy selects individual rows. The following TE rule allows Nancy to select only rows with the 'rxrow2_t' type:

 

  allow rxclient2_t rxrow2_t : db_tuple select;

 

Because no TE rule exist for rows of type 'rxrow1_t', rows with that type are filtered from the result set. Nancy's result set consists of 'Rowdata2' and 'Rowdata4'.

 

SELinux Type Enforcement