Project Overview

The SELinux Reference Policy project (refpolicy) is creating a complete SELinux policy as an alternative to the existing strict and targeted policies. What will set refpolicy apart?

	
Security: refpolicy has a mandate to develop security goals that are 	clear and rigoursly applied

	
Usability: refpolicy will be easier to understand and use.

	
Documentation: refpolicy has a structure that makes it possible to create 	in-depth documentation.

	
Flexibility: refpolicy will support source, loadable, and MLS modules 	with simple configuration.

Refpolicy is under active development, with support and full time development staff at Tresys Technology. We are looking for policy developers interested in contributing.

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 SELinux Reference Policy 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.

Background and Motivation

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.

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.