From f3791fbb146e04b14fb07373c2ab78218c7bf976 Mon Sep 17 00:00:00 2001
From: Chris PeBenito <cpebenito@tresys.com>
Date: Mon, 29 Aug 2005 17:16:46 +0000
Subject: [PATCH] massive revision

---
 www/html/index.html | 78 +++++++++++++++++++++++++--------------------
 1 file changed, 43 insertions(+), 35 deletions(-)

diff --git a/www/html/index.html b/www/html/index.html
index 6584c0b01..a10533708 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>
-