3.4. Summary
-
SELinux is implemented as an LSM module in the kernel. SELinux uses LSM hooks throughout the kernel to control access to kernel resources. Access decisions are made by the SELinux security server, which is part of the SELinux LSM module. The security policy enforced by the security server is loaded into the kernel via a privileged userspace interface. The AVC provides performance improvement for access validation.
The SELinux framework also supports userspace object managers through the
libselinux
library. In its basic form, the kernel security server directly provides access validation, whereas the library contains a
per-process
AVC. This approach requires the kernel to hold the policy for all userspace managers and to be aware of all userspace object classes.
-
The emerging policy server architecture enhances support for userspace object managers by providing a userspace security server that will enforce all portions of the policy relating to userspace objects, thereby
relieving
the kernel of its need to know of userspace object classes and policy rules. The policy server will also provide fine-grained access control to the policy itself, allowing greater distribution of policy management authority.
-
SELinux policies tend to be large and complex, necessitating the need for them to be
constructed
as a collection of modules. A common method is to use source modules, where all modules are built as part of a single, monolithic module. This is the method used in Red Hat Enterprise Linux 4 and Fedora
Core
4, and the one we assume in Part II.
-
A second modularity approach provides for loadable modules, where policy pieces can be constructed largely independent of other modules, and combined at install time on a running system. In the case of loadable modules, a base module is created in a manner similar to a monolithic policy, but with the expectation that the base module can be smaller and focused on the core operating system. Additional software packages will have their portion of the policy installed as separate loadable modules. This is the method being adopted by FC5.
Checkpolicy
is the policy compiler that takes a complete policy source file (
policy.conf
) and
validates
the syntax and semantics of the file and creates a binary policy file. In the case of loadable modules,
checkpolicy
compiles the base policy module, and the program
checkmodule
compiles the individual loadable modules.
|
