nnd
/
selinux-refpolicy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

massive revision

This commit is contained in:
Chris PeBenito 2005-08-29 17:16:46 +00:00
parent e7498c4de9
commit f3791fbb14
1 changed files with 43 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
www/html/index.html
View File

@ -14,12 +14,16 @@ Refpolicy is under active development, with support and full time development
staff from <a href="http://www.tresys.com/selinux">Tresys Technology</a>. The 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> 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 page. The <a href="index.php?page=status">status</a> page has more details on
what is included in the current release. This project always looking for policy what is included in the current release.
developers interested in <a href="index.php?page=contributing">contributing</a>. </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> </p>
<br> <br>
<h1>Project Goals</h1> <h1>Project Goals</h1>
<h2>Security</h2>
<p>Security is the reason for existence for SELinux policies and must, <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 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 state (secure or not secure) is not a sufficient goal for developing an SELinux
@ -30,12 +34,45 @@ 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 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: security goals as is practical. To accomplish this refpolicy will provide:
</p> </p>
<ul> <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 <li><b>Security Goals:</b> clearly stated security goals will for each
component of the policy. This will allow policy developers to component of the policy. This will allow policy developers to
determine if a given component meets their security needs. determine if a given component meets their security needs.
</li> </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 <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 operating system and serves as a foundation to the rest of the
policy. This base policy should be able to support a variety of policy. This base policy should be able to support a variety of
@ -43,42 +80,13 @@ security goals as is practical. To accomplish this refpolicy will provide:
</li> </li>
<li><b>Application Policy Variations:</b> application policy variations <li><b>Application Policy Variations:</b> application policy variations
that make different security tradeoffs. For example, two Apache that make different security tradeoffs. For example, two Apache
policies might be created. One that is for serving read-only, policies might be created, one that is for serving read-only
static content that is severely restricted and another that is static content that is severely restricted, and another that is
appropriate for dynamic content. appropriate for dynamic content.
</li> </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 <li><b>Multi-Level Security</b>: MLS will be supported out-of-the-box
without requiring destructive changes to the policy. It will be without requiring destructive changes to the policy. It will be
possible to compile and MLS and non-MLS policy from the same possible to compile and MLS and non-MLS policy from the same
policy files by switching a configuration option. policy files by switching a configuration option.
</li> </li>
</ul> </ul>
<h2>Usability and Documentation</h2>
<p>
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 aims to make aggressive improvements in this area,
making policies easier to develop, understand, and analyze. This will be
addressed through improved structuring and organization, the addition of
modularity and abstraction, and documentation. See
<a href="index.php?page=getting-started">getting started</a> and
<a href="index.php?page=documentation">documentation</a> for more information.
</p>
<h2>Flexibility and Configuration</h2>
<p>
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.
</p>