[selinux-policy: 604/3172] massive revision
Daniel J Walsh
dwalsh at fedoraproject.org
Thu Oct 7 19:56:53 UTC 2010
commit f3791fbb146e04b14fb07373c2ab78218c7bf976
Author: Chris PeBenito <cpebenito at tresys.com>
Date: Mon Aug 29 17:16:46 2005 +0000
massive revision
www/html/index.html | 78 ++++++++++++++++++++++++++++-----------------------
1 files changed, 43 insertions(+), 35 deletions(-)
---
diff --git a/www/html/index.html b/www/html/index.html
index 6584c0b..a105337 100644
--- a/www/html/index.html
+++ b/www/html/index.html
@@ -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
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. This project always looking for policy
-developers interested in <a href="index.php?page=contributing">contributing</a>.
+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>
-<h2>Security</h2>
<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
@@ -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
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
@@ -43,42 +80,13 @@ security goals as is practical. To accomplish this refpolicy will provide:
</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
+ 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>
-<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>
-
More information about the scm-commits
mailing list