93 lines
4.7 KiB
HTML
93 lines
4.7 KiB
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>
|