selinux-refpolicy/www/html/index.html

<h1>Project Overview</h1>
<p>
The SELinux Reference Policy project (refpolicy) is creating a complete SELinux
policy as an alternative to the existing strict and targeted policies available
from <a href="http://selinux.sf.net">http://selinux.sf.net</a>. Once complete,
this policy will be able to be used as the system policy for a variety of
systems and used as the basis for creating other policies. Refpolicy is based on
the current strict and targeted policies, but aims to accomplish many additional
goals.
</p>
<br/>
<p>
Refpolicy is under active development, with support and full time development
staff from <a href="http://www.tresys.com/selinux">Tresys Technology</a>. The
current release is available from the <a href="index.php?page=download">download</a>
page.  The <a href="index.php?page=status">status</a> page has more details on
what is included in the current release.
</p>
<br/>
<p>
The project is always looking for policy developers interested in <a href="index.php?page=contributing">contributing</a>.
See the <a href="index.php?page=getting-started">getting started</a> guide for
more information on writing Refpolicy modules.
</p>
<br>
<h1>Project Goals</h1>
<p>Security is the reason for existence for SELinux policies and must,
therefore, always be the first priority. The common view of security as a binary
state (secure or not secure) is not a sufficient goal for developing an SELinux
policy. In reality, different systems have different requirements and purposes
and corresponding differences in the meaning of secure. What is a fundamental
security flaw on one system might be the acceptable, or even the primary
functionality, of another. The challenge for a system policies like the current
strict and targeted policy or refpolicy is to support as many of these differring
security goals as is practical. To accomplish this refpolicy will provide:
</p>
<ul>
	<li><b>Strong Modularity:</b> central to the design of the policy is
		strict modularity. Access to resources are abstracted, and
		implementation details are encapsulated in the module.
	</li>
	<li><b>Security Goals:</b> clearly stated security goals will for each
		component of the policy. This will allow policy developers to
		determine if a given component meets their security needs.
	</li>
	<li><b>Documentation</b>: the difficulty and complexity of creating
		SELinux policies has become the number one barrier to the
		adoption of SELinux. It also potentially reduces the security
		of the policies: a policy that is too complex to easily
		understand is difficult to make secure. Refpolicy will make
		aggressive improvements in this area by including documentation
		for modules and their interfaces as a critical part of the
		infrastructure. See the <a href="index.php?page=documentation">documentation</a>
		page for more information.
	</li>
	<li><b>Development Tool Support</b>: In addition to documentation,
		Refpolicy aims to make improvements in this area, making
		policies easier to develop, understand, analyze, and verify by adding
		interface call backtraces which can be used for debugging and
		graphical development tools.
	</li>
	<li><b>Forward Looking:</b> Refpolicy aims to support a variety of
		policy configurations and formats, including standard source
		policies, MLS policies, and <a href="http://sepolicy-server.sourceforge.net/index.php?page=modules">loadable policy modules</a>
		all from the same source tree. This is done through the addition
		of infrastructure for automatically handling the differences
		between source and loadable module based policies and the
		additional MLS fields to all policy statements that include
		contexts.
	</li>
	<li><b>Configurability:</b> configuration tools that allow the
		policy developer to make important security decisions including
		defining roles, configuring networking, and trading legacy
		compatibility for increased security. 
	</li>
	<li><b>Flexible Base Policy:</b> a base policy that protects the basic
		operating system and serves as a foundation to the rest of the
		policy. This base policy should be able to support a variety of
		application policies with differing security goals.
	</li>
	<li><b>Application Policy Variations:</b> application policy variations
		that make different security tradeoffs. For example, two Apache
		policies might be created, one that is for serving read-only
		static content that is severely restricted, and another that is
		appropriate for dynamic content.
	</li>
	<li><b>Multi-Level Security</b>: MLS will be supported out-of-the-box
		without requiring destructive changes to the policy. It will be
		possible to compile and MLS and non-MLS policy from the same
		policy files by switching a configuration option.
	</li>
</ul>