Chapter 2. SELinux Policy Overview

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:


When you have the policy sources installed, rpm may assume that you have modified the policy and may not automatically load a newly installed policy. This occurs if you have ever loaded the policy from source, that is, run make load, make reload, or make install. New binary policy packages install policy.<XY> as, for example, $SELINUX_POLICY/policy.18.rpmnew.

If you have not modified the policy or want to use the binary policy package, you can mv policy.18.rpmnew policy.18, then touch /.autorelabel and reboot. If you have modified the policy and want to load your modifications, you must upgrade the policy source package and make load. Policy building is discussed in Chapter 7 Compiling SELinux Policy.

If you have only built the policy but never loaded it, that is, have only run make policy, you should not run into this situation. The binary policy installs cleanly, knowing that you are not running a custom policy.

Work is ongoing to improve package installation logic so the entire process is automated by rpm. Expect this to be included in a future update to Red Hat Enterprise Linux 4.

2.1. What Is 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.


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.