Section 11.1. Methods for Managing the Build Process


11.1. Methods for Managing the Build Process

If 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.

[1] When you hear criticism that SELinux is complex, you should view this comment with skepticism. Those who make this remark are usually implying that Linux is fine, but SELinux adds too much complexity. The reality is that SELinux simply exposes the complexity that is inherent to Linux. It does not add any. If you truly want to have comprehensive, strong security for Linux, there is no better option than SELinux. If you are content with partial solutions that provide incomplete (but simple) security solutions for this complex operating system, perhaps SELinux may not be to your taste. In any case, as we discuss later in this book, tools and methods are being developed to manage the complexities of Linux that SELinux exposes, so that you can have comprehensive security with increasing ease of use.

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.





SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net