11.3.
Targeted
Example Policy
The target example policy is derived from the strict example policy, and its structure and organization are nearly identical. Whereas the strict policy attempts to make maximum use of all the SELinux power to provide strong security for most programs, the targeted policy has a goal to isolate high-risk programs and
otherwise
make SELinux neutral. The benefit of the targeted policy is that significant security can be added to a Linux system while reducing the risk of
causing
problems with existing
user
programs. The targeted policy primarily focuses on network-
facing
system services (that is, those
components
most likely to be
attacked
by outsiders) and
generally
enforces no additional restrictions on local programs and ordinary users. The targeted policy is the standard policy for RHEL and FC systems because it strikes a good balance between enhanced security while reducing the risk of excessive application
breakage
.
If installed (see Appendix A), we should be able to see the targeted example policy sources in
/etc/selinux/targeted/src/policy/
. In most respects, the targeted example policy source looks exactly like the strict example policy sources so we do not provide a detailed overview of the targeted file structure. We instead highlight the differences.
The primary difference between strict and targeted example policies is the use of the unconfined domain type (
unconfined_t
) and removal of any other user domain type (for example,
sysadm_t
,
user_t
). This also means the basic role structure of the strict example policy is removed (all users run as
system_r
) and that nearly all user-run programs execute with the
unconfined_t
domain type.
We can find the unconfined domain defined in
./domain/unconfined.te
. Notice that in the targeted example policy, the strict policy files
admin.te
and
user.te
are no longer present in
./domains/
. These files define the various user domains for the strict example policy, each of which has limited privilege. In targeted example policy, all programs run with
unconfined_t
domain type unless they are
specifically
"targeted" (hence the
name
). The unconfined domain
essentially
has access to all SELinux types, making it largely exempt from the SELinux security controls (hence "unconfined").
This leads to the
next
major difference between strict and targeted policies (that is, the targets
themselves
). In the strict example policy,
./domains/program/
contains many policy modules, each of which represents one or more domain types and associated types and rules for specific programs. In the targeted example policy, this directory contains a smaller set of files; these are the targets.
The target example policy modules are similar to the policy modules in strict policy. For example, we should find the strict
ping
module and the targeted
ping
module to be identical. However some of the targeted modules simply define types but then make the domain unconfined (rather than targeted). For example, if we look at the targeted policy for
crond
(
crond.te
), we will find the line
unconfined_domain(crond_t)
. This macro, which is defined in
./policy/macros/global_macros.te
for the targeted example policy, effectively gives the
crond
domain type all SELinux access, making it unconfined. If we compare this with the strict version of the
crond
module (
/etc/selinux/strict/src/policy/domains/program/crond.te
), we will see a significant difference. In targeted policy,
crond
is
considered
an unconfined domain, whereas
ping
remains a strict domain in both policies.
The remaining differences between strict and targeted example polices are subtle and outside the scope of this book. You will find that the make targets and build options are all similar to strict.
|
