11.1. Methods for Managing the Build ProcessIf you have read through Part II, by now you might have concerns about the practicality of building a complete, comprehensive, and secure SELinux policy. Certainly an SELinux policy is rich and complex; necessarily so because SELinux provides fine-grained access control for the rich and complex Linux kernel and its interactions with the multitude of userspace applications.[1] Fear not. In this chapter, we discuss ways to manage the entire policy build process, and methods that the SELinux community has evolved to aide in this process.
The methods for building policies are changing and evolving at a rapid pace. In this chapter, we overview one prevalent means of building policies using the basic policy language tools and compilers. This kind of low-level policy development is currently the predominant method for creating and modifying SELinux policies. Higher-level development methods are being developed, but none are in practice yet. The method for building policies we discuss in this chapter, the example policy, is based on the original example policy released by NSA with the original SELinux. We discuss another method called the reference policy in Chapter 12, "Reference Policy." Both of these methods have common low-level characteristics (for example, a tree of source modules), an organization and build process, and macros used to provide basic abstractions over the core language. The example policy has been evolved through years of community development far beyond what was originally released by NSA. One of the principal enhancements has the ability to build both strict and targeted policies with two different variations of the policy source tree. Both of these example policy variations share common characteristics and are related to each other. The strict policy is based on an example policy that is most directly descended from the original NSA example policy. As its name implies, the strict policy attempts to provide a domain type for every program that reasonably requires a private domain. The strict policy has evolved through years of open source community development and reflects the most extensive collective knowledge of policy statements. A challenge with the strict policy is that by trying to be strict, it inevitably causes breakage with existing Linux applications, which expect looser security controls. For many users, these annoying application breakages are an unacceptable tradeoff for increased security. To address this concern, the concept of a targeted policy was created. A version of a targeted policy is the default policy released with Red Hat Enterprise Linux version 4 (RHEL4) and Fedora Core (FC) systems. The purpose of the targeted policy is to allow most programs to run as if they were not running on an SELinux system. These programs are called unconfined, and the concept is achieved by creating an unconfined domain that essentially has access to all types in the SELinux policy. In the targeted policy, the more confining rules are focused on a small set of critical, likely-to-be-attacked programs such as network-facing daemons. These programs run in restricted domains as in the strict policy. In this way, the targeted policy has less chance of causing problems with legacy applications by having fewer programs that have tighter security. With targeted policy, we do a have less strict security enhancements; for many system solutions, however, the targeted policy is adequate and a great improvement over current security practice. The targeted policy is also a nice way to start using the features of SELinux without having to immediately use them everywhere. In the remainder of this chapter, we provide an overview of the key features and capabilities of the strict and targeted example policy source trees. Warning The one area where change is rapid is policies. All the policy build methods we discuss (strict and targeted example policies in this chapter and the reference policy equivalents in Chapter 12) are constantly under development and change. Be aware that the specific conventions and organization of a policy source tree may have changed since the time of this book's writing. |