| General systems theory arose in the middle of the last century, as systems analysts discovered that systems of a variety of types share common characteristics. One such characteristic is that systems can often be understood at any of several levels, sometimes referred to as levels of abstraction . For example, scientists tell us that interactions among atoms and molecules are governed by the quantum mechanical properties of elementary particles. But much of chemistry can be understood without reference to these fundamental structures. Indeed, chemistry arose and prospered as a discipline before the discovery of quantum mechanics and elementary particles. To understand SELinux, it's important that its internal mechanisms ”such as access vectors ”be understood, because these govern the security decisions SELinux makes. Yet because SELinux is highly configurable, the runtime behavior of an SELinux system can be viewed as effectively determined by the system's SELinux policy, which operates at a higher level of abstraction than low-level mechanisms such as access vectors. The high flexibility of SELinux is due to the configurability of its policy. Hence the SELinux policy of any given system ”though likely to be more or less based on the SELinux sample policy distributed with the NSA's SELinux release ”is unlikely to exactly match the sample policy. Moreover, the SELinux sample policy is itself a living document. At the time of writing, work is underway to polish the SELinux implementation to be released as part of Fedora Core 2, and the policy is being updated regularly, even daily. The configurability of policy and the high frequency of policy change complicate explication of the policy in two ways. First, they raise the question: what version of the policy is being explained? And second, they imply that any explanation is likely to be quickly outdated . Fortunately, this analysis overstates the degree of difficulty. Over an extended period of time, the main features of the SELinux sample policy have remained relatively constant. And, as mentioned, most actual SELinux policies are based on the NSA's sample policy. So although policies vary and are subject to change, they remain more alike than different. In this chapter, I explain a generic SELinux policy based on the SELinux policy associated with Fedora Core 2. The policy is hypothetical in the sense that it's not identical to any actual policy at any actual time. But that's not to say that it's irrelevant or even artificial. Instead, it's intended to be representative of a cross-section of actual SELinux policies and therefore serve as a baseline for understanding other, more highly customized or developed policies. You'll find the generic SELinux policy described in this chapter a useful point of reference in understanding the behavior of typical SELinux systems. However, please bear in mind that the policy of your own SELinux system is unlikely to match precisely the one described in this chapter. More particularly, this chapter explains: -
The two forms (source and binary) of an SELinux policy -
The component files associated with a typical SELinux policy domain -
The structure of the directory tree that contains the SELinux source policy and the contents of each component directory | 