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
in various search parameters, it
has no effect when analyzing a binary policy.
|
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
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.
|
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 menu lets you choose
the kind of rule, such as allow,
neverallow, and
auditallow. In Figure 6-7, the menu for is squeezed in the image since it is disabled:
The menu lets you pick search
parameters. The selection for 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 and , 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 ,
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
=> .
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 .
You can search either by specific Boolean or with regular expressions.
You can reduce the quantity of output by deselecting
.
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
choice, since role transitions are
deprecated. Using the selection is
only useful in analyzing roles in older versions of the SELinux policy,
which will not appear in Red Hat Enterprise Linux. The menu is disabled because it is only used in the
deprecated role_transition analysis.
To search, set a , either as source
or any if you want to search for it in both positions in an
allow rule. Then you set a
value. The search result shows if the
source role may assume the targeted role.
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.
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.
