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 <a href="index.php?page=goals">goals</a>.
</p>
<br/>
<p>
Refpolicy is under active development, with support and full time development staff from <a href="http://www.tresys.com">Tresys Technology</a>. The first release is available from the <a href="index.php?page=download">download</a> page. This release is far from complete and is not usable as a drop in replacement for the existing policies. It is for interested policy developers and community members to examine and comment upon. The  <a href="index.php?page=status">status</a> page has more details on what is included in the current release. This project is just getting started and we are looking for policy developers interested in <a href="contributing.html">contributing</a>.
</p>

<h1>Project Goals</h1>
<h2>Security</h2>
<p>Security is the reason for existence for SELinux policies and must, therefore, always be the first priority. The security of operating systems and applications is often presented as a binary state: software is either secure or not secure. In reality, that view of security is inadequate. 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 or targeted policy and refpolicy is to support all of these differring security goals. To accomplish this refpolicy will provide:
</p>

<ul>
	<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>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>Configuration Tools:</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>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>
<h2>Usability and Documentation</h2>
<ul>
	<li>Security: refpolicy has a mandate to develop security goals that are clear and rigoursly applied</li>
	<li>Usability: refpolicy will be easier to understand and use.</li>
	<li>Documentation: refpolicy has a structure that makes it possible to create in-depth documentation.
	<li>Flexibility: refpolicy will support source, loadable, and MLS modules with simple configuration.</li>
</ul>

<h1>Roadmap</h1>

<table border="1" cellspacing="0" cellpadding="3">
<tr>
<th class="title" colspan="3">Reference Policy Roadmap</th>
</tr>

<tr>
<td class="header">Version</td><td class="header">Date</td><td class="header">Description</td>
</tr>

<tr>
<td>0.1</td><td>June 14, 2005</td><td>Initial public release, basic policy restructuring, minimal modules</td>
</tr>
<tr>
<td>0.2</td><td>July 2005</td><td>Restructuring complete, additional modules, improved infrastructure, and incorporated community feedback</td>
</tr>
<tr>
<td>0.3</td><td>August 2005</td><td>Additional modules, basic role infrastructure, and tested loadable module support</td>
</tr>
<tr>
<td>0.4</td><td>September 2005</td><td>Additional modules and complete role infrastructure and role separation</td>
</tr>
<tr>
<td>0.5</td><td>October 2005</td><td>Additional modules, targeted policy, and tested MLS support</td>
</tr>
<tr>
<td>0.6</td><td>December 2005</td><td>Additional modules and module variations</td>
</tr>