Complexities and best practices

As you can now appreciate, SELinux is complex, and can be thought of as a general purpose "meta programming policy language". You're literally programming what interactions are allowed to occur in a very complex OS such as Linux, where the interactions themselves are often complex. Just like a programming language, you can do things with different styles and methods that will yield differing results. Perhaps using a switch() in that program will make it cleaner and easier to understand rather than an else-if block, even though functionally you will end up with the same thing. SELinux is the same; you can often accomplish things with one portion of the enforcement mechanisms that would be more appropriately accomplished using an alternate mechanism. In later chapters, we will cover the process of labeling the target and subject, one of the more difficult parts of the system.

When someone authors a program, they often have a set of requirements in place that the software should perform. These are the requirements of the software. In SELinux, you should do the same thing. You should gather the security requirements and understand the threat models you wish to protect yourself from. A well designed SELinux policy would meet these goals. A great design would do it in a way that is easy to extend. That's ultimately where careful and judicious use of the combination of UBAC, RBAC, TE, and MLS will help achieve the requirements and design goals.