* Notes in <warning> should not begin with 'Please note that'. The

<warning> tag already expresses this information and so the text will
  be rendered appropriately.
* Improve wording in synopsis.
* Remove redundant sentences and simplify section about what will not
  be covered in this chapter.
* Omit unnecessary words and improve grammar as appropriate
* Remove redundant paragraph.
* Use serial comma in list of elements, as mandated by doc project primer.

en_US.ISO8859-1/books/handbook/mac/chapter.sgml

@@ -104,11 +104,11 @@
     </itemizedlist>
 
     <warning>
-      <para>Please note that the improper use of the
-	following information may cause loss of access to the system,
+      <para>The improper use of the
+	information in this chapter may cause loss of access to the system,
 	aggravation of users, or inability to access the features
-	provided by &xfree86;.  Most importantly, <acronym>MAC</acronym> should not
-	be believed to completely secure a system.  The
+	provided by &xfree86;.  More importantly, <acronym>MAC</acronym> should not
+	be relied upon to completely secure a system.  The
 	<acronym>MAC</acronym> framework only augments
 	existing security policy; without sound security practices and
 	regular security checks, the system will never be completely
@@ -127,20 +127,16 @@
     <sect2>
       <title>What Will Not Be Covered</title>
 
-      <para>This chapter covers a broad range of security in respect
-	to the <acronym>MAC</acronym> framework.  It is important to
-	note that the development of <acronym>MAC</acronym> policies
-	will not be covered.  Writing new policies is completely beyond
-	the initial scope of this document.  As such, some policies
-	included with the <acronym>MAC</acronym> framework are not
-	covered.  These include the &man.mac.test.4;, &man.mac.stub.4;
-	and &man.mac.none.4; modules/policies.  Each of these modules
-	have specific characteristics which are provided for both
-	testing and new module development.</para>
-
-      <para>For more information on these modules and the various
-	mechanisms they provide, review the manual pages
-	provided.</para>
+      <para>This chapter covers a broad range of security issues relating
+	to the <acronym>MAC</acronym> framework, however, the
+	development of new <acronym>MAC</acronym> policies
+	will not be covered.  A number of modules included with the
+	<acronym>MAC</acronym> framework have specific characteristics
+	which are provided for both testing and new module
+	development. These include the &man.mac.test.4;,
+	&man.mac.stub.4; and &man.mac.none.4; modules/policies.
+        For more information on these modules and the various
+	mechanisms they provide, please review the manual pages.</para>
     </sect2>
   </sect1>
 
@@ -194,7 +190,7 @@
 	  under the direction of a <emphasis>subject</emphasis>.
 	  This includes directories, files, fields, screens, keyboards,
 	  memory, magnetic storage, printers or any other data
-	  storage/moving device.  Basically a data container, or
+	  storage/moving device.  Basically, an object is a data container or
 	  a system resource; access to an <emphasis>object</emphasis>
 	  effectively means access to the data.</para>
       </listitem>
@@ -259,8 +255,8 @@
       carefully select the correct policies.  Some environments
       may need to limit access control over the network; in these
       cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and even
-      &man.mac.biba.4; might be a good starting point.  In other
-      cases, the need to secret items on the file system might
+      &man.mac.biba.4; policies might make good starting points.  In other
+      cases, strict confidentiality of file system objects might
       be required.  Policies such as &man.mac.bsdextended.4;
       and &man.mac.mls.4; exist for this purpose.</para>
 
@@ -288,23 +284,17 @@
       leakage.</para>
 
     <para>Thus, each policy has a unique way of dealing with
-      information flow.  Policy selection should be completely based
+      information flow.  Policy selection should be based
       on a well thought out security policy.  In many cases, the
       overall policy may need to be revised and reimplemented across
       the network.  Understanding the different policies offered by
-      the <acronym>MAC</acronym> framework will help administrators to
+      the <acronym>MAC</acronym> framework will help administrators
       choose the best policies for their situations.</para>
 
-    <para>Also, understanding the implications involved with
-      implementing the <acronym>MAC</acronym> framework into a
-      specific environment; the following configuration must be
-      completed before trying any of the examples or applying
-      the information in the rest of this chapter to any
-      environment.</para>
-
     <para>The default &os; kernel does not include the option for
       the <acronym>MAC</acronym> framework; thus the following
-      kernel option must be added:</para>
+      kernel option must be added before trying any of the examples or
+      applying the information in this chapter to any &os; environment:</para>
 
     <programlisting>options	MAC</programlisting>
 
@@ -322,7 +312,7 @@
   <sect1 id="mac-understandlabel">
     <title>Understanding MAC Labels</title>
 
-    <para>A <acronym>MAC</acronym> label is virtually a security
+    <para>A <acronym>MAC</acronym> label is a virtual security
       stamp which may be applied to subjects and objects throughout
       the system.</para>
 
@@ -346,7 +336,7 @@
 
     <para>With every policy which supports the labeling feature in
       &os;, three specific predefined labels are offered, they
-      are the low, high and equal labels.  Although they enforce
+      are the low, high, and equal labels.  Although they enforce
       access control in a different manner with each policy, you
       can be sure that the low label will be the lowest setting,
       the equal label will set the subject or object to be disabled
@@ -395,7 +385,7 @@
 	the configuration.</para>
 
       <para>All configuration may be done by use of the
-	&man.setfmac.8; and &man.setpmac.8; utilities respectively.
+	&man.setfmac.8; and &man.setpmac.8; utilities.
 	The <command>setfmac</command> command is used to set
 	<acronym>MAC</acronym> labels on system objects while the
 	<command>setpmac</command> command is used to set the labels on system
@@ -403,7 +393,7 @@
 
       <screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
 
-      <para>If no errors occurred with the command above a prompt
+      <para>If no errors occurred with the command above, a prompt
 	will be returned.  The only time these commands are not
 	quiescent is when an error occurred.  In some cases this
 	error may be a <errorname>Permission denied</errorname> and
@@ -417,7 +407,7 @@
 &prompt.root; <userinput>getfmac test</userinput>
 test: biba/high</screen>
 
-      <para>As can be observed, <command>setpmac</command>
+      <para>As we see above, <command>setpmac</command>
 	can be used to override the policy's settings by assigning
 	a different label to the invoked process.  The
 	<command>getpmac</command> utility is usually used with currently
@@ -425,7 +415,7 @@ test: biba/high</screen>
 	although it takes a process ID in place of
 	a command the logic is extremely similar.  It should be pointed
 	out that users will only be able to override policy labels if
-	they themselves own the object or subject.  If users would
+	they themselves own the object or subject.  If users
 	attempt to manipulate a file not in their access levels, the
 	<errorname>Operation not permitted</errorname> error
 	will be displayed by the <function>mac_set_link</function>