Section 12.1. Goals of the Reference Policy

12.1. Goals of the Reference Policy

The reference policy project is an effort to reengineer the existing policies derived from the National Security Agency (NSA) example policy into an easier to use, understand, and maintain policy. The primary goals are to create a strong design philosophy in policy development by applying well-understood software design principles, while retaining the years of experience learned by community effort in developing the existing policies. In other words, keep the good and fix the bad.

Chief among the "bad" with the existing example policy is its lack of strong modularity and the tight coupling of the policy source modules that results. Although macros add abstraction to the example policy, all policy identifiers (types, roles, attributes, and so on) are, in reality, global. Editing one policy module might require knowledge of many others and interdependency among modules is pervasive and poorly documented. Likewise, creating a new policy module requires detailed understanding of the implementation details of other policy modules.

Some of the key characteristics of the reference policy that make policy development easier and more understandable are as follows:

• A single source tree that supports (without destructive modification) strict and targeted policies, optional multilevel security/multicategory security (MLS/MCS) extensions, a single kernel policy file (called a monolithic policy), and the new loadable module infrastructure.

• Application of strong design principles, chiefly in the area of loosely coupled modules, with well-defined interfaces and no global use of type and other identifiers. (So, for example, all changes relating to a type are made entirely within a single module.)

• Integrated documentation support, capturing descriptions of module interfaces so that, for example, a policy module developer can use an interface without having to understand how the interface is implemented in the module.

• Simplify and standardize policy configuration and build options, so in general policy module writing and customization is easier and requires less expertise.

Besides making policy development easier, the reference policy also intends to make verifying the security properties of a policy easier to achieve (for example, for security certifications) and to increase support for high-level developments tools, such as graphical integrated development environments and sophisticated policy debuggers.

The reference policy is new, but we expect it to gain popularity as the definitive "reference" for building SELinux systems. At the time of this writing, Fedora Core 5 (FC5) has changed its supported policy from the older targeted example policy to a targeted policy based on the reference policy.

Warning

The reference policy is new at the time of this writing, with its initial development just nearing completion. Therefore, it is likely that some details of the reference policy have changed since this book was published.

For more information on the reference policy project and the latest policy sources, see the project's Web site at http://serefpolicy.sourceforge.net. If you are using an FC5 system, your default targeted policy is likely based on a reference policy build. If you have a reference policy installed on your system according to our instructions in Appendix A, "Obtaining SELinux Sample Policies," you can find the reference policy source files in /etc/selinux/refpolicy/src/policy. If you obtained a reference policy source tree from your distribution, the source files may be in a different directory under the /etc/selinux/ directory. (FC5 installs its version of the targeted reference policy in /etc/selinux/targeted/.) All path names we use in this chapter are relative to the policy source root directory.