The reference policy project was started to reengineer the example policy derived from the original example policy for SELinux. The goals of this reengineering include the inclusion of modern software engineering design principles to make policy development and maintenance easier to perform, and to support emerging technology, such as loadable modules and sophisticated policy development tools.
Layering is a weak design principle of reference policy. The layers organize policy modules in a manner that are generally reflective of our understanding of how the policy modules relate.
Modularity is a strong design principle of reference policy. Although the example policy had a form of modularity, it was weakly defined and did not ensure that modules remained loosely coupled. Reference policy modules hide implementation details from other modules allowing easier maintenance of the overall policy and distributed policy development (that is, the ability to develop a policy module without detailed knowledge of other modules).
Two properties of modularity primarily ensure that reference policy modules remain loosely coupled: encapsulation and abstraction.
Encapsulation ensures that implementation details of a module are only required by the module itself. This goal is achieved primarily through requiring that type and attribute names always remain local identifiers that may only be explicitly used by the module that defines them. Other modules use these types and attributes via well-defined interfaces of the module.
Abstraction ensures that policy module writers can think about policy development logically rather than focus on all the policy details. This is accomplished via module interfaces. Interfaces are designed and named to describe what the interface provides and not how it does it. The "how" can change over time without impacting the "what."
A module consists of three files: the private policy file (.te), the external interface file (.if), and the labeling policy file (.fc). All three files must be present for each defined module even if empty.
A reference policy module may have two types of interfaces: access and template. Access interfaces are by far the most common. These interfaces provide access to the module's private types and attributes. Template interfaces are less common and are used when we need to manage derived types between two modules.
Reference policy introduces two configuration files that provide most of the policy build options we need to control. The build.conf file controls global policy build options, such as policy type and install location. The modules.conf file controls which policy modules are built and in what form.
Currently, reference policy can build six types of policies from the same source tree: strict, targeted, strict-mls, targeted-mls, strict-mcs, and targeted-mcs.
Two types of builds are supported by the reference policy. A monolithic build creates a single kernel binary policy. Monolithic policies are the only type of policy in general use at the time of this writing and are the type of policy we mostly discuss in this book. A loadable module build creates a base module and a number of loadable modules that make use of the new loadable module infrastructure. We expect loadable modules to become more common going forward.
