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.