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.
