This chapter is an overview of SELinux policy, some of its
internals, and how it works. This chapter discusses the policy in a
more general way, where Chapter 3 Targeted Policy
Overview focuses on the details of the targeted policy as
it ships in Red Hat Enterprise Linux. This chapter starts with a
brief overview of what policy is and where it resides. Next, the
role of SELinux during boot is discussed. This is followed by
discussions on file security contexts, object classes and
permissions, attributes, types, access vectors, macros, users and
roles, constraints, and a brief discussion summarizing special
kernel interfaces.
To see all of the details discussed in this chapter, you must
make sure you have installed the policy source and binary packages
for the targeted policy:
Policy is the set of rules that guide the SELinux security
engine. It defines types for file objects and domains for
processes, uses roles to limit the domains that can be entered, and
has user identities to specify the roles that can be attained. A
domain is what a type is called when it is
applied to a process.
A type is a way of grouping together like items based on their
fundamental security sameness. This doesn't necessarily have to do
with the unique purpose of an application or the content of a
document. For example, an object such as a file can have any type
of content and be for any purpose, but if it belongs to a user and
lives in that user's home directory, it is considered to be of a
specific security type, user_home_t.
These object types gain their sameness because they are
accessible in the same way by the same set of subjects. Similarly,
processes tend to be of the same type if they have the same
permissions as other subjects. In the targeted policy, programs
that run in the unconfined_t
domain have an executable with a type such as sbin_t. From an SELinux perspective, that
means they are all equivalent in terms of what they can and cannot
do on the system.
For example, the binary executable file object at /usr/bin/postgres has the type of postgresql_exec_t. All of the targeted
daemons have their own *_exec_t
type for their executable applications. In fact, the entire set of
PostgreSQL executables such as createlang,
pg_dump, and pg_restore have the same type, postgresql_exec_t, and they transition to
the same domain, postgresql_t,
upon execution.
The policy defines various rules that say how each domain may
access each type. Only what is specifically allowed by the rules is
permitted. By default every operation is denied and audited,
meaning it is logged in $AUDIT_LOG, such
as /var/log/messages. Policy is compiled
into binary format for loading into the kernel security server, and
as the security server hands out decisions, these are cached in the
AVC for performance.
Policy can be administratively defined, either by modifying the
existing files or adding local TE and file context files to the
policy tree. Such a new policy can be loaded into the kernel in
real time. Otherwise, the policy is loaded during boot by
init, as explained in Section 2.3 Policy Role in
Boot. Ultimately, every system operation is determined by
the policy and the type labeling of the files.
|
Important |
|
After loading a new policy, it is recommended to restart any
services that may have new or changed labeling. For the most part,
this is only the targeted daemons, as listed in Section 3.1
What is the Targeted Policy?.
|
SELinux is an implementation of domain-type access control, with
role-based limiting. The policy specifies the rules in that
environment. It is written in a simple language created
specifically for writing security policy. Policy writers use
m4 macros to capture common sets of
low-level rules. There are a number of m4
macros defined in the existing policy, which assist greatly in
writing new policy. These rules are preprocessed into many
additional rules as part of building policy.conf, which is compiled into the binary
policy.
The files are divided into various categories in a policy tree
at $SELINUX_SRC/. This is covered in
Section 3.2 Files and
Directories of the Targeted Policy. Access rights are
divided differently among domains, and no domain is required to act
as a master for all other domains. Entering and switching domains
is controlled by the policy, through login programs, userspace
programs such as newrole, or by requiring
a new process execution in the new domain, called a transition.