6.3. Using apol for Policy Analysis
There are many aspects to a formal security policy analysis. In this guide, policy analysis refers to analyzing SELinux policy to discover the relationship between types defined in the policy. This section presents apol, which is designed specifically for analyzing policy.
Policy analysis is not only performed on running systems, but is an integral part of designing and writing a policy. You can analyze your custom policy using apol as part of your testing process, before you load it on a machine. apol can help you discover unexpected and undesirable results of your policy writing decisions. It helps show the differences between versions or kinds of policy. For example, you can analyze each iteration of your policy, reusing saved queries, looking for information leaks or unwanted transitions.
Policy analysis with apol is many magnitudes more complex than audit log analysis with seaudit. The setools package comes with several important documents to read in order to understand how to properly utilize apol, as well as how to interpret your results. Reading the documentation from /usr/share/doc/setools-<version> is recommended:
apol_help.txt — This detailed help file describes how to use all of the features of apol, as well as a walkthrough of the tabbed interface.
dta_help.txt — This is an overview of domain transition analysis (DTA), which studies the ability of processes to change their domains in a particular policy.
iflow_help.txt — This is an overview of information flow analysis, which finds the expected and unexpected possible routes information can travel between two types in a policy.
types_relation_help.txt — This help file discusses analyzing the relationship between two types. Information flow analysis is essentially what you are doing when you analyze the policy.
The topics each of these help files covers is central to the task of analyzing SELinux policy. The apol UI is organized around these tasks. The following sections explain these tasks, discussing how to utilize the GUI for your analysis work.
 | Note |
|---|---|
Both the source policy.conf and binary policy.<XY> files can be analyzed by apol. Much of the results are similar, but there are noteworthy differences. This is because the binary compilation process strips out attributes as well as the initial SIDs. It is the lack of attributes that most affects the analysis process. When analyzing a binary policy, attributes cannot be included as search parameters. The policy.conf tab is disabled for the binary policy, as well as the Initial SIDs tab under the Policy Components tab. The field Attributes is empty, and although you can select Attrib(ute)s in various search parameters, it has no effect when analyzing a binary policy. |
6.3.1. Policy Component Analysis
When opening the policy file, apol gathers and organizes information. The same information is difficult to identify and extrapolate manually going through the policy files. For example, there is no master list within the policy source of which types belong to which attributes. This information is scattered throughout the policy. apol gathers and displays these SELinux categories.
Figure 6-6 shows the Policy Components tab. Within this tab there are tabs for Types, Classes/Perms, Roles, Users, Booleans, and Initial SIDs. Under each tab is the capability to perform basic searches.
| Note |
|---|---|
There are declared types that do not have any rules written for them or file contexts set for them. For example, swapfile_t is declared in $SELINUX_SRC/types/file.te, so it appears in the Types menu within the Types tab. However, the file type is not assigned to any file nor are there rules about it. If you are wondering if a particular type is used in the policy, you can search for it under the Policy Rules tab. If no rules are found, then it is an unused type. |
 | Tip |
|---|---|
One feature of the Booleans tab is that you can set Boolean values within the policy loaded into apol. This does not affect the Boolean value on the disk or in memory. This lets you test the effect on the policy of changing different Booleans, entirely within apol. You can then do TE rule and information flow analysis with the new Boolean settings. |
6.3.2. TE Rule Analysis
Rule analysis looks into the relationship between a pair of types, trying to find the ways they interact. The interaction could be direct or indirect due to the use of attributes, and enabled or disabled by a Boolean setting.
Under the Policy Rules tab are search options and regular expression fields for defining the source and target type or attribute. The Rule Selection menu lets you choose the kind of rule, such as allow, neverallow, and auditallow. In Figure 6-7, the menu for Default Type is squeezed in the image since it is disabled:
The Search Options menu lets you pick search parameters. The selection for Only search for enabled rules refers to the Boolean value for a rule, or if a conditional expression (ifdef statement) is true. This selection is a filter that can hide or reveal a large number of possible routes between a pair of types.
If you expand your search to include disabled conditional rules, you can have the results highlighted. By selecting Mark enabled conditional rules and Mark disabled conditional rules, the conditional rules are identified and marked with their status of Enabled or Disabled.
The search parameter tabs Types/Attributes and Classes/Permissions let you describe details about the source and target you are analyzing. An asterisk * appears on the tab if a parameter from that tab is set and affecting the search. You can define the source by using the exact type or using a regular expression. Automatically, the expression is anchored at both ends, so a caret ^ and dollar sign $ surround the search terms unless you explicitly change them.
You can choose to Include Indirect Matches, which expands the search to include attributes. You may choose to search by type and/or by attribute, with searching by attribute being similar to including indirect matches.
You can further refine or expand the search using the object classes and associated permissions under the Classes/Permissions tab.
The search results are displayed in a tabular format, with a different search result and its search parameters for each tab. Switching between search result tabs changes the search parameters. You can keep up to ten results open at a time.
To start a new search, you click New, which displays the results in a new tab. You can change the search parameters and click Update, which updates the search within the existing tab. This allows you to keep track of many different parts of an analysis. You can save queries for later recall using Query => Save Query.
Example 6-1 shows the contents of a search result field from the Type Enforcement Rules Display area. The search that generated these results included searching for enabled and disabled conditional rules with display. The type searched for is ^httpd_t$ as a source and/or target. The comments following the mark ## are explanations inserted for this guide and are not part of the standard apol output.
278 rules match the search criteria
Number of enabled conditional rules: 23
Number of disabled conditional rules: 34
(3813) allow httpd_t var_log_t:dir { read getattr lock \
search ioctl add_name write };
(3815) allow httpd_t httpd_log_t:file { create ioctl read \
getattr lock append };
(3821) allow httpd_t httpd_log_t:dir { setattr read \
getattr lock search ioctl add_name write };
(3825) allow httpd_t httpd_log_t:lnk_file read;
(3882) allow httpd_t unconfined_t:fd use;
(3884) allow httpd_t unconfined_t:process sigchld;
## These are related to the Boolean httpd_disable_trans,
## showing that it is not set to true:
(4024) allow unconfined_t httpd_t:process transition; [Enabled]
(4074) allow httpd_t unconfined_t:process sigchld; [Enabled]
(4086) allow httpd_t unconfined_t:fd use; [Enabled]
(4088) allow unconfined_t httpd_t:fd use; [Enabled]
(4098) allow httpd_t unconfined_t:fifo_file { ioctl read \
getattr lock write append }; [Enabled]
(4108) allow httpd_t httpd_exec_t:file { read getattr lock \
execute ioctl }; [Enabled]
(4118) allow httpd_t httpd_exec_t:file entrypoint; [Enabled]
(4126) allow unconfined_t httpd_t:process { noatsecure \
siginh rlimitinh }; [Enabled]
## These are part of other httpd_* Booleans that are set
## to false in the file /etc/selinux/targeted/booleans:
(4554) allow httpd_t httpd_sys_script_t:process transition; \
[Disabled]
(4594) allow httpd_t httpd_sys_script_exec_t:file { read getattr \
execute }; [Disabled]
(4604) allow httpd_sys_script_t httpd_t:process sigchld; [Disabled]
(4616) allow httpd_sys_script_t httpd_t:fd use; [Disabled]
(4618) allow httpd_t httpd_sys_script_t:fd use; [Disabled] |
Example 6-1. apol TE Rules Search Results
Within the search results, there are hyperlinks to the left of each rule. The number corresponds to the line number in policy.conf, and clicking on, for example, (3813) switches your view to the policy.conf tab, taking you directly to line 3813. These hyperlinks are only visible if you have apol analyzing the policy.conf file.
If you are using a binary policy file such as policy.18, the rules are compiled and not available for viewing. The top-level tab policy.conf is not present when analyzing the binary policy.
There are two other search capabilities within the Policy Rules tab, the Conditional Expressions and RBAC Rules tabs.
The Conditional Expressions tab allows you to search just the conditional expressions, viewing the rules within them. The only searchable rule types are allow, audit, and transition. All conditional expressions are displayed in the default view; you can narrow the view using Search Options.
You can search either by specific Boolean or with regular expressions. You can reduce the quantity of output by deselecting Display rules within conditional expression(s).
Each rule is marked if it is [enabled] or [disabled], which shows the current state of that conditional in the policy. Changing a value in the Booleans tab within the Policy Components tab is reflected in the Conditional Expressions Display by running your search again. This is another way of analyzing the consequences of toggling a Boolean value, entirely within apol.
The last tab under the Policy Rules tab is the RBAC Rules tab. Effectively, you only use the Allow choice, since role transitions are deprecated. Using the Transition selection is only useful in analyzing roles in older versions of the SELinux policy, which will not appear in Red Hat Enterprise Linux. The Default Role menu is disabled because it is only used in the deprecated role_transition analysis.
To search, set a Source Role, either as source or any if you want to search for it in both positions in an allow rule. Then you set a Target Role value. The search result shows if the source role may assume the targeted role.
6.3.3. Domain Transition Analysis
Domain transition is one important aspect of TE. Since being in a particular domain is the key to controlling that domain's derivative types, the strict control of what domains can transition to what other domains is essential to SELinux security.
Domain transition is looked at from two directions, forward and reverse. In a forward analysis, you select a source type and search to find all target types it can transition to. You can use search parameters to refine the results. For a reverse analysis, you select a target type and discover all the source types that can transition to the target type.
For a domain transition to occur, there must be three particular allow rules. These rules control the source domain that is attempting to transition to the target domain. One rule permits the process transition itself, a second rule allows the source access to the entry point executable for the target domain, and the third rule allows the target domain itself to use the executable as an entry point.
Domain transition analysis with apol centers around identifying these three rules. In some cases, more than one appropriate rule is found. The extensive help file, /usr/share/doc/setools-<version>/dta_help.txt , is useful in explaining this analysis.
6.3.4. Direct and Transitive Information Flow
Information flow analysis is a central and challenging part of analyzing an SELinux policy. Your analysis may find unexpected or dangerous information flows. For example, if you want to be sure that the content in your /home/ directories (user_home_dir_t) is flowing as you configured it into the httpd_t domain, apol searches through the policy to reveal all the ways information flows between the two types. This search is show in Figure 6-8:
Information flow analysis can be a challenging and daunting task. The policy holds thousands or tens of thousands of rules with hundreds of types, all interacting in multiple ways. The help file /usr/share/doc/setooles-<version>/iflow_help.txt is essential reading for understanding information flow analysis in SELinux.
In doing transitive information flow analysis, apol attempts to string together different direct flows, looking for ways that information can transit between direct flows. This looks for ways that allow the farthest ends of the different direct flows to pass information to each other.