2005-05-17 19:58:58 +00:00
|
|
|
<h1>Security Enhanced Linux (SELinux) Reference Policy</h1>
|
|
|
|
|
2005-05-17 19:51:41 +00:00
|
|
|
<h3>Introduction</h3>
|
2005-05-17 19:58:58 +00:00
|
|
|
<P>
|
|
|
|
The purpose of this document is to serve as a blueprint to policy developers
|
|
|
|
and serves as the initial means for communicating the motivations, approach and
|
|
|
|
goals of the <i>SELinux Reference Policy</i> development project. This document
|
|
|
|
is intended for SELinux policy developers and other members of the SELinux
|
|
|
|
development community interested in building a secure foundation upon which to
|
|
|
|
build high-assurance solutions using SELinux. The reference policy will provide
|
|
|
|
a carefully designed and consistent system security policy that can be used as
|
|
|
|
a basis for developing secure solutions using SELinux.
|
|
|
|
</p>
|
2005-05-17 19:51:41 +00:00
|
|
|
|
|
|
|
<h3>Background and Motivation</h3>
|
2005-05-17 19:58:58 +00:00
|
|
|
<P>
|
|
|
|
One of the key motivations for this project is the drive to get SELinux
|
|
|
|
mainstreamed into commercial products. True, SELinux is currently being
|
|
|
|
incorporated into various commercial distributions, but clearly, widespread
|
|
|
|
adoption of SELinux as a commercial product eventually will require the
|
|
|
|
operating system to be certified. Efforts are already underway by IBM for
|
|
|
|
SELinux to undergo a Common Criteria evaluation under the Labeled Security
|
|
|
|
Protection Profile (LSPP). Furthermore, SELinux needs a more robust policy
|
|
|
|
structure upon which to build high-assurance solutions, such as intrusion
|
|
|
|
detection systems (IDS), cross-domain solutions, etc., particularly for
|
|
|
|
government and DoD security-critical missions.
|
|
|
|
</p>
|
2005-05-17 19:51:41 +00:00
|
|
|
|
2005-05-17 19:58:58 +00:00
|
|
|
<P>
|
|
|
|
Unfortunately, the current "strict" policy for SELinux does not meet the
|
|
|
|
requirements of high security systems. The policy chooses functionality over
|
|
|
|
security, with the implicit goal of not breaking legacy application behavior.
|
|
|
|
Additionally, it has no clear security goals and those that exist are not
|
|
|
|
rigorously followed or are ignored to preserve functionality. Furthermore,
|
|
|
|
complexity is increasing in the policy and the situation is not improving.
|
|
|
|
</p>
|