You are here SELinux / SELinux Process Type Transition

SELinux Process Type Transition


SELinux provides facilities (i.e., SELinux rules) to allow a Linux process to change its context Type during the execution of a program. Upon execution, the process's Type is changed to a new Type and upon program exit the process's Type is restored to the original Type. Typically, the new Type is required to perform some trusted functionality, such as checking a user's password. The result is that the trusted functionality is enabled only while the trusted program is being executed. This way the assured logic of the program is tightly bundled with the privileges needed to execute the program. If the user is not executing the program then they have no ability to perform the trusted functionality and if they are executing the program then there is better assurance that the trusted functionality will not be exploited.

 

Once a trusted program has been configured, SELinux rules are used to control which users may execute the trusted program, based upon the user's Type. Thus, the SELinux RBAC mechanism may be used to control who may perform the trusted functionalities. 

 

An application of the SELinux process type transition is demonstrated by the following example and diagram. In the example there is a trusted program called UpgradeInsert. The UpgradeInsert program is an ODBC application that takes row data as an argument and then inserts that data as a row with an MLS level of s1. This occurs despite the user's process context being at an MLS level of s0. Thus, the program upgrades the level of the row data from s0 to s1. Additionally, the upgrade is only allowed to occur if the row data meets some contextual requirements, such as the absence of "dirty words".

 

While there are other methods to accomplish inserting an upgraded row (see notes below), here the program transitions to the Type associated with the Trusted RUBIX Security Administrator role. This allows the UpgradeInsert program to use the Trusted RUBIX 'ALTER SESSION' command to change the DBMS session context to have an upgraded level of s1 prior to performing an INSERT, resulting in the new row having the upgraded level. The UpgradeInsert program also will perform some dirty word checks and other filtering to ensure the value being upgraded is acceptable.

 

In our example, the user 'Bob' has the ability to execute the UpgradeInsert program using the trusted functionality while user 'Nancy' does not. This is because Nancy does not have basic SELinux execute abilities for the program. Also, Nancy has no SELinux abilities to perform a process Type transition. If Nancy were allowed to execute the program without a Type transition then the DBMS server would reject the ALTER SESSION command because the Trusted RUBIX Security Administrator role is required.

 

The sequential steps performed in using the UpgradeInsert program are: 

 

Step 1: The user executes the UpgradeInsert program. The row data (e.g., UpgradeData1) that will be inserted is passed as the program's only argument. At this step SELinux performs a number of actions: 1) it checks that the user's Type has basic execute abilities for the Type of the program (see rule B in the diagram); 2) if an appropriate type_transition rule exists and the user's Type has rules to allow the transition, the user's Type will be changed to the new Type (see rules C, D, and E in the diagram); 3) if no type_transition rule exists, no Type change occurs prior to execution. In our example, Bob is allowed to execute the program with a type transition to rubix_secadm_t (as specified in rule C) while Nancy is denied execution.

 

Step 2: Bob's process Type is set to the new Type (rubix_secadm_t) and the UpgradeInsert program is executed. At this point, because of the rubix_secadm_t Type, Bob's process has the abilities of the Trusted RUBIX Security Administrator.

 

Step 3: The command-line argument is parsed and the row data (UpgadeData1) is filtered to ensure it is an acceptable value for upgrading. This functionality is entirely application dependent. 

 

Step 4: If the row data is not aceptable for upgrading, the program exists with an error. Bob's process Type is automatically restored to its original value (rxclient1_t). 

 

Step 5: The program connects to the Trusted RUBIX DBMS server. The DBMS session context will be extracted from Bob's process and will be rxuser1_u:rxclient1_t:rubix_secadm_t:s0.

 

Step 6: The program issues the 'ALTER TABLE SET LABEL' SQL command to set the DBMS session label to have a Level of s1. This step ensures that any data subsequently inserted will have a Level of s1. Note that only a user operating in the Trusted RUBIX Security Administrator role may execute this functionality. If a normal user was allowed to execute the UpgradeInsert program but there were no applicable  type_transition rule, then the DBMS server would disallow this operation.

 

Step 7: The row is constructed from the UpgradeData1 argument and inserted into the database. Because of the ALTER SESSION command issued in step 6, the new row will have a Level of s1.

 

Step 8: The program disconnects from the Trusted RUBIX DBMS.

 

Step 9: The program exists after having successfully inserted a row at the upgraded Level of s1. Bob's process Type is automatically restored to its original value (rxclient1_t).

 

1Note: The SELinux range_transition rule will allow a process's Level to transition during a program's execution. This is as opposed to the Type transition (type_transition rule) used in the example. Had the range_transition rule been used, the process would transition directly to the s1 Level and the row would be inserted. There would be no need for the 'ALTER SESSION' command. The current method was chosen for the example to demonstrate the use of a Trusted RUBIX administrative role. So, the example shown could be modified to make use of the Trusted RUBIX DBA role to allow the program to supersede DBMS DAC.

 

2Note: A similar example could also have been used where the new Type of the process transition allows DBMS operations to be performed that would not be permitted by the original Type. For example, the process could transition from rxclient1_t to rxclient_trusted_t and then SELinux Type Enforcement rules would allow only rxclient_trusted_t to perform the trusted DBMS operations (e.g., SELECT, UPDATE). 

 

Diagram of Trusted Program (UpgradeInsert) Using Process Type Transition