This patch addresses the following:

- removes etc. and i.e.
- fixes some title capitalization
- fixes incorrect grammar and overuse of ;
- fixes verb tense from future to active
- fixes redundancy
- general rewording to make a densely written dense subject slightly less dense
- link added for trustedbsd website
- spell out of acronyms introduced on first instance in section and used as acronym for all other instances
- remove reference to trustedbsd mailing lists as these have only seen spam posts in past 6 years
- reference to SEBSD was removed as does not exist
- reference to deprecated lomac confusion removed
- fix varname tags
- note added that as of 8.x, MAC is in GENERIC

Approved by:  bcr (mentor)

1 files changed, 725 insertions, 891 deletions

diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
index 6d95c5f8ca..38c622d0e3 100644
--- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
@@ -27,44 +27,42 @@
     </indexterm>
 
     <para>&os;&nbsp;5.X introduced new security extensions from the
-      TrustedBSD project based on the &posix;.1e draft.  Two of the
+      <ulink url="http://www.trustedbsd.org">TrustedBSD
+	Project</ulink> based on the &posix;.1e draft.  Two of the
       most significant new security mechanisms are file system Access
       Control Lists (<acronym>ACL</acronym>s) and Mandatory Access
-      Control (<acronym>MAC</acronym>) facilities.  Mandatory Access
-      Control allows new access control modules to be loaded,
-      implementing new security policies.  Some provide protections
-      of a narrow subset of the system, hardening a particular
-      service.  Others provide comprehensive labeled security across
-      all subjects and objects.  The mandatory part of the definition
-      comes from the fact that the enforcement of the controls is
-      done by administrators and the system, and is not left up to
-      the discretion of users as is done with discretionary access
-      control (<acronym>DAC</acronym>, the standard file and System
-      V <acronym>IPC</acronym> permissions on &os;).</para>
-
-    <para>This chapter will focus on the
-      Mandatory Access Control Framework (<acronym>MAC</acronym>
-      Framework), and a set of pluggable security policy modules
-      enabling various security mechanisms.</para>
+      Control (<acronym>MAC</acronym>) facilities.  MAC allows new
+      access control modules to be loaded, implementing new security
+      policies.  Some modules provide protections for a narrow subset
+      of the system, hardening a particular service.  Others provide
+      comprehensive labeled security across all subjects and objects.
+      The mandatory part of the definition indicates that enforcement
+      of controls is performed by administrators and the operating
+      system.  This is in contrast to the default security mechanism
+      of Discretionary Access Control (<acronym>DAC</acronym> where
+      enforcement is left to the discretion of users.</para>
+
+    <para>This chapter focuses on the <acronym>MAC</acronym> framework
+      and the set of pluggable security policy modules &os; provides
+      for enabling various security mechanisms.</para>
 
     <para>After reading this chapter, you will know:</para>
 
     <itemizedlist>
       <listitem>
-	<para>What <acronym>MAC</acronym> security policy modules
-	  are currently included in &os; and their associated
-	  mechanisms.</para>
+	<para>Which <acronym>MAC</acronym> security policy modules
+	  are included in &os; and their associated mechanisms.</para>
       </listitem>
 
       <listitem>
-	<para>What <acronym>MAC</acronym> security policy modules
-	  implement as well as the difference between a labeled and
-	  non-labeled policy.</para>
+	<para>The capabilities of <acronym>MAC</acronym> security
+	  policy modules as well as the difference between a labeled
+	  and non-labeled policy.</para>
       </listitem>
 
       <listitem>
-	<para>How to efficiently configure a system to use
-	  the <acronym>MAC</acronym> framework.</para>
+	<para>How to efficiently configure a system to use the
+	  <acronym>MAC</acronym> framework.</para>
       </listitem>
 
       <listitem>
@@ -74,8 +72,7 @@
 
       <listitem>
 	<para>How to implement a more secure environment using the
-	  <acronym>MAC</acronym> framework and the examples
-	  shown.</para>
+	  <acronym>MAC</acronym> framework.</para>
       </listitem>
 
       <listitem>
@@ -94,36 +91,27 @@
       </listitem>
 
       <listitem>
-	<para>Be familiar with
-	  the basics of kernel configuration/compilation
-	  (<xref linkend="kernelconfig"/>).</para>
-      </listitem>
-
-      <listitem>
 	<para>Have some familiarity with security and how it
 	  pertains to &os; (<xref linkend="security"/>).</para>
       </listitem>
     </itemizedlist>
 
     <warning>
-      <para>The improper use of the
-	information contained herein may cause loss of system access,
-	aggravation of users, or inability to access the features
-	provided by X11.  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
-	secure.</para>
-
-      <para>It should also be noted that the examples contained
-	within this chapter are just that, examples.  It is not
-	recommended that these particular settings be rolled out
-	on a production system.  Implementing the various security
-	policy modules takes a good deal of thought and testing.  One
-	who does not fully understand exactly how everything works
-	may find him or herself going back through the entire system
-	and reconfiguring many files or directories.</para>
+      <para>Improper <acronym>MAC</acronym> configuration may cause
+	loss of system access, aggravation of users, or inability to
+	access the features provided by
+	<application>Xorg</application>.  More importantly,
+	<acronym>MAC</acronym> should not be relied upon to completely
+	secure a system.  The <acronym>MAC</acronym> framework only
+	augments an existing security policy.  Without sound security
+	practices and regular security checks, the system will never
+	be completely secure.</para>
+
+      <para>The examples contained within this chapter are for
+	demonstration purposes and the example settings should
+	<emphasis>not</emphasis> be implemented on a production
+	system.  Implementing any security policy takes a good deal of
+	understanding, proper design, and thorough testing.</para>
     </warning>
 
     <sect2>
@@ -135,10 +123,10 @@
 	modules will not be covered.  A number of security policy
 	modules included with the <acronym>MAC</acronym> framework
 	have specific characteristics which are provided for both
-	testing and new module development.  These include the
+	testing and new module development.  These include
 	&man.mac.test.4;, &man.mac.stub.4; and &man.mac.none.4;.
 	For more information on these security policy modules and
-	the various mechanisms they provide, please review the manual
+	the various mechanisms they provide, refer to their manual
 	pages.</para>
     </sect2>
   </sect1>
@@ -147,127 +135,117 @@
     <title>Key Terms in This Chapter</title>
 
     <para>Before reading this chapter, a few key terms must be
-      explained.  This will hopefully clear up any confusion that
-      may occur and avoid the abrupt introduction of new terms
-      and information.</para>
+      explained:</para>
 
     <itemizedlist>
       <listitem>
-	<para><emphasis>compartment</emphasis>: A compartment is a
-	  set of programs and data to be partitioned or separated,
-	  where users are given explicit access to specific components
-	  of a system.  Also, a compartment represents a grouping,
-	  such as a work group, department, project, or topic.  Using
-	  compartments, it is possible to implement a need-to-know
-	  security policy.</para>
+	<para><emphasis>compartment</emphasis>: a set of programs and
+	  data to be partitioned or separated, where users are given
+	  explicit access to specific component of a system.  A
+	  compartment represents a grouping, such as a work group,
+	  department, project, or topic.  Compartments make it
+	  possible to implement a need-to-know-basis security
+	  policy.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>high water mark</emphasis>: A high water mark
-	  policy is one which permits the raising of security levels
-	  for the purpose of accessing higher level information.  In
-	  most cases, the original level is restored after the process
+	<para><emphasis>high-watermark</emphasis>: this type of
+	  policy permits the raising of security levels for the
+	  purpose of accessing higher level information.  In most
+	  cases, the original level is restored after the process
 	  is complete.  Currently, the &os; <acronym>MAC</acronym>
-	  framework does not have a policy for this, but the
-	  definition is included for completeness.</para>
+	  framework does not include this type of policy.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>integrity</emphasis>: Integrity, as a key
-	  concept, is the level of trust which can be placed on data.
-	  As the integrity of the data is elevated, so does the
-	  ability to trust that data.</para>
+	<para><emphasis>integrity</emphasis>: the level of trust which
+	  can be placed on data.  As the integrity of the data is
+	  elevated, so does the ability to trust that data.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>label</emphasis>: A label is a security
-	  attribute which can be applied to files, directories, or
-	  other items in the system.  It could be considered a
-	  confidentiality stamp; when a label is placed on a file it
-	  describes the security properties for that specific
-	  file and will only permit access by files, users, resources,
-	  etc. with a similar security setting.  The meaning and
-	  interpretation of label values depends on the policy
-	  configuration: while some policies might treat a label as
-	  representing the integrity or secrecy of an object, other
-	  policies might use labels to hold rules for access.</para>
+	<para><emphasis>label</emphasis>: a security attribute which
+	  can be applied to files, directories, or other items in the
+	  system.  It could be considered a confidentiality stamp.
+	  When a label is placed on a file, it describes the security
+	  properties of that file and will only permit access by
+	  files, users, and resources with a similar security setting.
+	  The meaning and interpretation of label values depends on
+	  the policy configuration.  Some policies treat a label as
+	  representing the integrity or secrecy of an object while
+	  other policies might use labels to hold rules for
+	  access.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>level</emphasis>: The increased or decreased
+	<para><emphasis>level</emphasis>: the increased or decreased
 	  setting of a security attribute.  As the level increases,
 	  its security is considered to elevate as well.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>low water mark</emphasis>: A low water mark
-	  policy is one which permits lowering of the security levels
-	  for the purpose of accessing information which is less
-	  secure.  In most cases, the original security level of the
-	  user is restored after the process is complete.  The only
-	  security policy module in &os; to use this is
-	  &man.mac.lomac.4;.</para>
+	<para><emphasis>low-watermark</emphasis>: this type of
+	  policy permits lowering security levels for the purpose of
+	  accessing information which is less secure.  In most cases,
+	  the original security level of the user is restored after
+	  the process is complete.  The only security policy module in
+	  &os; to use this is &man.mac.lomac.4;.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>multilabel</emphasis>: The
-	  <option>multilabel</option> property is a file system option
-	  which can be set in single user mode using the
-	  &man.tunefs.8; utility, during the boot operation
-	  using the &man.fstab.5; file, or during the creation of
-	  a new file system.  This option will permit an administrator
-	  to apply different <acronym>MAC</acronym> labels on
-	  different objects.  This option only applies to security
-	  policy modules which support labeling.</para>
+	<para><emphasis>multilabel</emphasis>: this property is a file
+	  system option which can be set in single user mode using
+	  &man.tunefs.8;, during boot using &man.fstab.5;, or during
+	  the creation of a new file system.  This option permits
+	  an administrator to apply different <acronym>MAC</acronym>
+	  labels on different objects.  This option only applies to
+	  security policy modules which support labeling.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>object</emphasis>: An object or system
-	  object is an entity through which information flows
-	  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, an object is a data
-	  container or a system resource; access to an
-	  <emphasis>object</emphasis> effectively means access to the
-	  data.</para>
+	<para><emphasis>object</emphasis>: an entity through which
+	  information flows under the direction of a
+	  <emphasis>subject</emphasis>.  This includes directories,
+	  files, fields, screens, keyboards, memory, magnetic storage,
+	  printers or any other data storage or moving device.  An
+	  object is a data container or a system resource.  Access to
+	  an <emphasis>object</emphasis> effectively means access to
+	  its data.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>policy</emphasis>: A collection of rules
+	<para><emphasis>policy</emphasis>: a collection of rules
 	  which defines how objectives are to be achieved.  A
 	  <emphasis>policy</emphasis> usually documents how certain
-	  items are to be handled.  This chapter will
-	  consider the term <emphasis>policy</emphasis> in this
-	  context as a <emphasis>security policy</emphasis>; i.e.
-	  a collection of rules which will control the flow of data
-	  and information and define whom will have access to that
-	  data and information.</para>
+	  items are to be handled.  This chapter considers the term
+	  <emphasis>policy</emphasis> to be a <emphasis>security
+	  policy</emphasis>, or a collection of rules which controls
+	  the flow of data and information and defines who has access
+	  to that data and information.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>sensitivity</emphasis>: Usually used when
-	  discussing <acronym>MLS</acronym>.  A sensitivity level is
-	  a term used to describe how important or secret the data
+	<para><emphasis>sensitivity</emphasis>: usually used when
+	  discussing Multilevel Security <acronym>MLS</acronym>.  A
+	  sensitivity level describes how important or secret the data
 	  should be.  As the sensitivity level increases, so does the
-	  importance of the secrecy, or confidentiality of the
+	  importance of the secrecy, or confidentiality, of the
 	  data.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>single label</emphasis>: A single label is
-	  when the entire file system uses one label to
-	  enforce access control over the flow of data.  When a file
-	  system has this set, which is any time when the
-	  <option>multilabel</option> option is not set, all
-	  files will conform to the same label setting.</para>
+	<para><emphasis>single label</emphasis>: a policy where the
+	  entire file system uses one label to enforce access control
+	  over the flow of data.  Whenever <option>multilabel</option>
+	  is not set, all files will conform to the same label
+	  setting.</para>
       </listitem>
 
       <listitem>
-	<para><emphasis>subject</emphasis>: a subject is any
-	  active entity that causes information to flow between
-	  <emphasis>objects</emphasis>; e.g., a user, user process,
-	  system process, etc.  On &os;, this is almost always a
+	<para><emphasis>subject</emphasis>: any active entity that
+	  causes information to flow between
+	  <emphasis>objects</emphasis> such as a user, user process,
+	  or system process.  On &os;, this is almost always a
 	  thread acting in a process on behalf of a user.</para>
       </listitem>
     </itemizedlist>
@@ -280,99 +258,71 @@
       <acronym>MAC</acronym> framework augments the security of
       the system as a whole.  The various security policy modules
       provided by the <acronym>MAC</acronym> framework could be used
-      to protect the network and file systems, block users from
-      accessing certain ports and sockets, and more.  Perhaps the
-      best use of the policy modules is to blend them together, by
-      loading several security policy modules at a time for a
-      multi-layered security environment.  In a multi-layered security
-      environment, multiple policy modules are in effect to keep
-      security in check.  This is different to a hardening policy,
-      which typically hardens elements of a system that is used only
-      for specific purposes.  The only downside is administrative
-      overhead in cases of multiple file system labels, setting
-      network access control user by user, etc.</para>
-
-    <para>These downsides are minimal when compared to the lasting
-      effect of the framework; for instance, the ability to pick
-      and choose which policies are required for a specific
-      configuration keeps performance overhead down.  The reduction
-      of support for unneeded policies can increase the overall
-      performance of the system as well as offer flexibility of
-      choice.  A good implementation would consider the overall
-      security requirements and effectively implement the various
-      security policy modules offered by the framework.</para>
-
-    <para>Thus a system utilizing <acronym>MAC</acronym> features
-      should at least guarantee that a user will not be permitted
-      to change security attributes at will; all user utilities,
-      programs and scripts must work within the constraints of
-      the access rules provided by the selected security policy
-      modules; and that total control of the <acronym>MAC</acronym>
-      access rules are in the hands of the system
-      administrator.</para>
-
-    <para>It is the sole duty of the system administrator to
-      carefully select the correct security policy modules.  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; policy modules might make good starting
-      points.  In other cases, strict confidentiality of file system
-      objects might be required.  Policy modules such as
-      &man.mac.bsdextended.4; and &man.mac.mls.4; exist for this
-      purpose.</para>
+      to protect the network and file systems or to block users from
+      accessing certain ports and sockets.  Perhaps the best use of
+      the policy modules is to load several security policy modules at
+      a time in order to provide a <acronym>MLS</acronym> environment.
+      This approach differs from a hardening policy, which typically
+      hardens elements of a system which are used only for specific
+      purposes.  The downside to <acronym>MLS</acronym> is increased
+      administrative overhead.</para>
+
+    <para>The overhead is minimal when compared to the lasting effect
+      of a framework which provides the ability to pick and choose
+      which policies are required for a specific configuration and
+      which keeps performance overhead down.  The reduction of support
+      for unneeded policies can increase the overall performance of
+      the system as well as offer flexibility of choice.  A good
+      implementation would consider the overall security requirements
+      and effectively implement the various security policy modules
+      offered by the framework.</para>
+
+    <para>A system utilizing <acronym>MAC</acronym> guarantees that a
+      user will not be permitted to change security attributes at
+      will.  All user utilities, programs, and scripts must work
+      within the constraints of the access rules provided by the
+      selected security policy modules and total control of the
+      <acronym>MAC</acronym> access rules are in the hands of the
+      system administrator.</para>
+
+    <para>It is the duty of the system administrator to
+      carefully select the correct security policy modules.  For an
+      environment that needs to limit access control over the network,
+      the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4;
+      policy modules make good starting points.  For an environment
+      where strict confidentiality of file system objects is required,
+      consider the &man.mac.bsdextended.4; and &man.mac.mls.4; policy
+      modules.</para>
 
     <para>Policy decisions could be made based on network
-      configuration.  Perhaps only certain users should be permitted
-      access to facilities provided by &man.ssh.1; to access the
-      network or the Internet.  The &man.mac.portacl.4; would be
-      the policy module of choice for these situations.  But what
-      should be done in the case of file systems?  Should all access
-      to certain directories be severed from other groups or specific
-      users?  Or should we limit user or utility access to specific
-      files by setting certain objects as classified?</para>
-
-    <para>In the file system case, access to objects might be
-      considered confidential to some users, but not to others.
-      For an example, a large development team might be broken
-      off into smaller groups of individuals.  Developers in
-      project A might not be permitted to access objects written
-      by developers in project B.  Yet they might need to access
-      objects created by developers in project C; that is quite a
-      situation indeed.  Using the different security policy modules
-      provided by the <acronym>MAC</acronym> framework; users could
-      be divided into these groups and then given access to the
-      appropriate areas without fear of information
-      leakage.</para>
-
-    <para>Thus, each security policy module has a unique way of
-      dealing with the overall security of a system.  Module selection
-      should be based on a well thought out security policy.  In many
-      cases, the overall policy may need to be revised and
-      reimplemented on the system.  Understanding the different
+      configuration.  If only certain users should be permitted
+      access to &man.ssh.1;, the &man.mac.portacl.4; policy module is
+      a good choice.  In the case of file systems, access to objects
+      might be considered confidential to some users, but not to
+      others.  As an example, a large development team might be
+      broken off into smaller projects where  developers in project A
+      might not be permitted to access objects written by developers
+      in project B.  Yet both projects might need to access objects
+      created by developers in project C.  Using the different
+      security policy modules provided by the <acronym>MAC</acronym>
+      framework, users could be divided into these groups and then
+      given access to the appropriate objects.</para>
+
+    <para>Each security policy module has a unique way of dealing with
+      the overall security of a system.  Module selection should be
+      based on a well thought out security policy which may require
+      revision and reimplementation.  Understanding the different
       security policy modules offered by the <acronym>MAC</acronym>
       framework will help administrators choose the best policies
       for their situations.</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 before trying any of the examples or
-      information in this chapter:</para>
-
-    <programlisting>options	MAC</programlisting>
-
-    <para>And the kernel will require a rebuild and a
-      reinstall.</para>
-
     <caution>
-      <para>While the various manual pages for <acronym>MAC</acronym>
-	policy modules state that they may be built into the kernel,
-	it is possible to lock the system out of
-	the network and more.  Implementing <acronym>MAC</acronym>
-	is much like implementing a firewall, care must be taken
-	to prevent being completely locked out of the system.  The
-	ability to revert back to a previous configuration should be
-	considered while the implementation of <acronym>MAC</acronym>
-	remotely should be done with extreme caution.</para>
+      <para>Implementing <acronym>MAC</acronym> is much like
+	implementing a firewall, care must be taken to prevent being
+	completely locked out of the system.  The ability to revert
+	back to a previous configuration should be considered and the
+	implementation of <acronym>MAC</acronym> remotely should be
+	done with extreme caution.</para>
     </caution>
   </sect1>
 
@@ -383,65 +333,55 @@
       which may be applied to subjects and objects throughout
       the system.</para>
 
-    <para>When setting a label, the user must be able to comprehend
-      what it is, exactly, that is being done.  The attributes
-      available on an object depend on the policy module loaded, and
-      that policy modules interpret their attributes in different
-      ways.  If improperly configured due to lack of comprehension,
-      or the inability to understand the implications, the result
-      will be the unexpected and perhaps, undesired, behavior of the
-      system.</para>
+    <para>When setting a label, the administrator must be able to
+      comprehend what exactly is being done and understand any
+      implications in order to prevent unexpected or undesired
+      behavior of the system.  The attributes available on an object
+      depend on the loaded policy module as policy modules interpret
+      their attributes in different ways.</para>
 
     <para>The security label on an object is used as a part of a
       security access control decision by a policy.  With some
-      policies, the label by itself contains all information necessary
-      to make a decision; in other models, the labels may be processed
-      as part of a larger rule set, etc.</para>
-
-    <para>For instance, setting the label of
-      <literal>biba/low</literal> on a file will represent a label
-      maintained by the Biba security policy module, with a value
-      of <quote>low</quote>.</para>
+      policies, the label contains all of the information necessary
+      to make a decision.  In other policies, the labels may be
+      processed as part of a larger rule set.  For instance, setting
+      the label of <literal>biba/low</literal> on a file will
+      represent a label maintained by the Biba security policy module,
+      with a value of <quote>low</quote>.</para>
 
     <para>A few policy modules which support the labeling feature
-      in &os; offer three specific predefined labels.  These
-      are the low, high, and equal labels.  Although they enforce
-      access control in a different manner with each policy module,
-      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
-      or unaffected, and the high label will enforce the highest
-      setting available in the Biba and <acronym>MLS</acronym>
+      in &os; offer three specific predefined labels:  low, high, and
+      equal.  Such policy modules enforce access control in a
+      different manner with each policy module, where the low label is
+      the lowest setting, the equal label sets the subject or object
+      to be disabled or unaffected, and the high label enforces the
+      highest setting available in the Biba and <acronym>MLS</acronym>
       policy modules.</para>
 
     <para>Within single label file system environments, only one
-      label may be used on objects.  This will enforce one set of
+      label may be used on objects.  This label enforces one set of
       access permissions across the entire system and in many
       environments may be all that is required.  There are a few
       cases where multiple labels may be set on objects or subjects
-      in the file system.  For those cases, the
-      <option>multilabel</option> option may be passed to
+      in the file system by passing <option>multilabel</option> to
       &man.tunefs.8;.</para>
 
     <para>In the case of Biba and <acronym>MLS</acronym>, a numeric
       label may be set to indicate the precise level of hierarchical
       control.  This numeric level is used to partition or sort
-      information into different groups of say, classification only
+      information into different groups of classification only
       permitting access to that group or a higher group level.</para>
 
-    <para>In most cases the administrator will only be setting up a
-      single label to use throughout the file system.</para>
-
-    <para><emphasis>Hey wait, this is similar to
-	<acronym>DAC</acronym>!  I thought <acronym>MAC</acronym> gave
-	control strictly to the administrator.</emphasis>  That
-      statement still holds true, to some extent as
+    <para>In most cases, the administrator will set up a single label
+      to use throughout the file system.  This is similar to
+      <acronym>DAC</acronym> to some extent as
       <username>root</username> is the one in control and who
       configures the policies so that users are placed in the
       appropriate categories/access levels.  Alas, many policy modules
       can restrict the <username>root</username> user as well.  Basic
       control over objects will then be released to the group, but
       <username>root</username> may revoke or modify the settings
-      at any time.  This is the hierarchal/clearance model covered
+      at any time.  This is the hierarchical/clearance model covered
       by policies such as Biba and <acronym>MLS</acronym>.</para>
 
     <sect2>
@@ -453,32 +393,29 @@
 	configuration or the manipulation and verification of
 	the configuration.</para>
 
-      <para>All configuration may be done by use of the
-	&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 subjects.  Observe:</para>
+      <para>All configuration may be done using &man.setfmac.8; and
+	&man.setpmac.8;.  <command>setfmac</command> is used to set
+	<acronym>MAC</acronym> labels on system objects while
+	<command>setpmac</command> is used to set the labels on system
+	subjects.  Observe:</para>
 
       <screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
 
-      <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; similarly to the
-	&man.chmod.1; and &man.chown.8; commands.  In some cases this
-	error may be a <errorname>Permission denied</errorname> and
-	is usually obtained when the label is being set or modified
-	on an object which is restricted.<footnote><para>Other conditions
-	  may produce different failures.  For instance, the file may
-	  not be owned by the user attempting to relabel the object,
-	  the object may not exist or may be read only.  A mandatory
-	  policy will not allow the process to relabel the file, maybe
+      <para>If the configuration is successful, the prompt will be
+	returned without error.  A common error is
+	<errorname>Permission denied</errorname> which usually occurs
+	when the label is being set or modified on an object which is
+	restricted.<footnote>Other conditions may produce different
+	  failures.  For instance, the file may not be owned by the
+	  user attempting to relabel the object, the object may not
+	  exist, or the object may be read only.  A mandatory policy
+	  will not allow the process to relabel the file, maybe
 	  because of a property of the file, a property of the
 	  process, or a property of the proposed new label value.  For
-	  example: a user running at low integrity tries to change the
+	  example, a user running at low integrity tries to change the
 	  label of a high integrity file.  Or perhaps a user running
 	  at low integrity tries to change the label of a low
-	  integrity file to a high integrity label.</para></footnote>  The
+	  integrity file to a high integrity label.</footnote>  The
 	system administrator may use the following commands to
 	overcome this:</para>
 
@@ -488,18 +425,16 @@
 &prompt.root; <userinput>getfmac test</userinput>
 test: biba/high</screen>
 
-      <para>As we see above, <command>setpmac</command>
-	can be used to override the policy module's settings by
-	assigning a different label to the invoked process.  The
-	<command>getpmac</command> utility is usually used with
-	currently running processes, such as
-	<application>sendmail</application>: although it takes a
-	process ID in place of a command the logic is extremely
-	similar.  If users attempt to manipulate a file not in their
-	access, subject to the rules of the loaded policy modules,
-	the <errorname>Operation not permitted</errorname> error
-	will be displayed by the <function>mac_set_link</function>
-	function.</para>
+      <para><command>setpmac</command> can be used to override the
+	policy module's settings by assigning a different label to the
+	invoked process.  <command>getpmac</command> is usually used
+	with currently running processes, such as
+	<application>sendmail</application>.  It takes a process ID in
+	place of a command.  If users attempt to manipulate a file not
+	in their access, subject to the rules of the loaded policy
+	modules, the <errorname>Operation not permitted</errorname>
+	error will be displayed by the
+	<function>mac_set_link</function> function.</para>
 
       <sect3>
 	<title>Common Label Types</title>
@@ -507,15 +442,14 @@ test: biba/high</screen>
 	<para>For the &man.mac.biba.4;, &man.mac.mls.4; and
 	  &man.mac.lomac.4; policy modules, the ability to assign
 	  simple labels is provided.  These take the form of high,
-	  equal and low, what follows is a brief description of
-	  what these labels provide:</para>
+	  equal, and low, where:</para>
 
 	<itemizedlist>
 	  <listitem>
 	    <para>The <literal>low</literal> label is considered the
 	      lowest label setting an object or subject may have.
-	      Setting this on objects or subjects will block their
-	      access to objects or subjects marked high.</para>
+	      Setting this on objects or subjects blocks their access
+	      to objects or subjects marked high.</para>
 	  </listitem>
 
 	  <listitem>
@@ -531,66 +465,62 @@ test: biba/high</screen>
 	</itemizedlist>
 
 	<para>With respect to each policy module, each of those
-	  settings will instate a different information flow
-	  directive.  Reading the proper manual pages will further
-	  explain the traits of these generic label
+	  settings will establish a different information flow
+	  directive.  Refer to the manual pages of the module to
+	  determine the traits of these generic label
 	  configurations.</para>
 
 	<sect4>
 	  <title>Advanced Label Configuration</title>
 
 	  <para>Numeric grade labels are used for
-	    <literal>comparison:compartment+compartment</literal>;
-	    thus the following:</para>
+	    <literal>comparison:compartment+compartment</literal>.
+	    For example:</para>
 
 	  <programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting>
 
-	  <para>May be interpreted as:</para>
-
-	  <para><quote>Biba Policy Label</quote>/<quote>Grade
+	  <para>may be interpreted as <quote>Biba Policy
+	      Label</quote>/<quote>Grade
 	      10</quote>:<quote>Compartments 2, 3 and 6</quote>:
 	    (<quote>grade 5 ...</quote>)</para>
 
 	  <para>In this example, the first grade would be considered
 	    the <quote>effective grade</quote> with
 	    <quote>effective compartments</quote>, the second grade
-	    is the low grade and the last one is the high grade.
-	    In most configurations these settings will not be used;
-	    indeed, they offered for more advanced
-	    configurations.</para>
+	    is the low grade, and the last one is the high grade.
+	    In most configurations, these settings will not be used
+	    as they are advanced configurations.</para>
 
-	  <para>When applied to system objects, they will only have a
-	    current grade/compartments as opposed to system subjects
-	    as they reflect the range of available rights in the
-	    system, and network interfaces, where they are used for
-	    access control.</para>
+	  <para>System objects only have a current grade/compartment.
+	    System subjects reflect the range of available rights in
+	    the system, and network interfaces, where they are used
+	    for access control.</para>
 
 	  <para>The grade and compartments in a subject and object
-	    pair are used to construct a relationship referred to as
+	    pair are used to construct a relationship known as
 	    <quote>dominance</quote>, in which a subject dominates an
 	    object, the object dominates the subject, neither
 	    dominates the other, or both dominate each other.  The
 	    <quote>both dominate</quote> case occurs when the two
 	    labels are equal.  Due to the information flow nature of
-	    Biba, you have rights to a set of compartments,
-	    <quote>need to know</quote>, that might correspond to
-	    projects, but objects also have a set of compartments.
-	    Users may have to subset their rights using
-	    <command>su</command> or <command>setpmac</command> in
-	    order to access objects in a compartment from which they
-	    are not restricted.</para>
+	    Biba, a user has rights to a set of compartments that
+	    might correspond to projects, but objects also have a set
+	    of compartments.  Users may have to subset their rights
+	    using <command>su</command> or <command>setpmac</command>
+	    in order to access objects in a compartment from which
+	    they are not restricted.</para>
 	</sect4>
       </sect3>
 
       <sect3>
 	<title>Users and Label Settings</title>
 
-	<para>Users themselves are required to have labels so that
-	  their files and processes may properly interact with the
-	  security policy defined on the system.  This is
-	  configured through the <filename>login.conf</filename> file
-	  by use of login classes.  Every policy module that uses
-	  labels will implement the user class setting.</para>
+	<para>Users are required to have labels so that their files
+	  and processes properly interact with the security policy
+	  defined on the system.  This is configured in
+	  <filename>login.conf</filename> using login classes.  Every
+	  policy module that uses labels will implement the user class
+	  setting.</para>
 
 	<para>An example entry containing every policy module setting
 	  is displayed below:</para>
@@ -619,49 +549,49 @@ test: biba/high</screen>
 	:ignoretime@:\
 	:label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:</programlisting>
 
-	<para>The <literal>label</literal> option is used to set the
+	<para>To set the
 	  user class default label which will be enforced by
-	  <acronym>MAC</acronym>.  Users will never be permitted to
-	  modify this value, thus it can be considered not optional
-	  in the user case.  In a real configuration, however, the
-	  administrator will never wish to enable every policy module.
-	  It is recommended that the rest of this chapter be reviewed
-	  before any of this configuration is implemented.</para>
+	  <acronym>MAC</acronym>, use <option>label</option>.  Users
+	  are never permitted to modify this value.  In a real
+	  configuration, however, the administrator would never enable
+	  every policy module.  It is recommended that the rest of
+	  this chapter be reviewed before any configuration is
+	  implemented.</para>
 
 	<note>
-	  <para>Users may change their label after the initial login;
-	    however, this change is subject constraints of the policy.
-	    The example above tells the Biba policy that a process's
-	    minimum integrity is 5, its maximum is 15, but the default
-	    effective label is 10.  The process will run at 10 until
-	    it chooses to change label, perhaps due to the user using
-	    the setpmac command, which will be constrained by Biba to
-	    the range set at login.</para>
+	  <para>Users may change their label after they login, subject
+	    to the constraints of the policy.  The example above tells
+	    the Biba policy that a process's minimum integrity is 5,
+	    its maximum is 15, and the default effective label is 10.
+	    The process will run at 10 until it chooses to change
+	    label, perhaps due to the user using &man.setpmac.8;,
+	    which will be constrained by Biba to the configured
+	    range.</para>
 	</note>
 
-	<para>In all cases, after a change to
+	<para>After any change to
 	  <filename>login.conf</filename>, the login class capability
-	  database must be rebuilt using <command>cap_mkdb</command>
-	  and this will be reflected throughout every forthcoming
-	  example or discussion.</para>
-
-	<para>It is useful to note that many sites may have a
-	  particularly large number of users requiring several
-	  different user classes.  In depth planning is required
-	  as this may get extremely difficult to manage.</para>
+	  database must be rebuilt using
+	  <command>cap_mkdb</command>.</para>
+
+	<para>Many sites have a large number of users requiring
+	  several different user classes.  In depth planning is
+	  required as this may get extremely difficult to
+	  manage.</para>
       </sect3>
 
       <sect3>
 	<title>Network Interfaces and Label Settings</title>
 
-	<para>Labels may also be set on network interfaces to help
-	  control the flow of data across the network.  In all cases
-	  they function in the same way the policies function with
-	  respect to objects.  Users at high settings in
-	  <literal>biba</literal>, for example, will not be permitted
-	  to access network interfaces with a label of low.</para>
+	<para>Labels may be set on network interfaces to help
+	  control the flow of data across the network.  Policies
+	  using network interface labels function in the same way that
+	  policies function with respect to objects.  Users at high
+	  settings in <literal>biba</literal>, for example, will not
+	  be permitted to access network interfaces with a label of
+	  low.</para>
 
-	<para>The <option>maclabel</option> may be passed to
+	<para><option>maclabel</option> may be passed to
 	  <command>ifconfig</command> when setting the
 	  <acronym>MAC</acronym> label on network interfaces.  For
 	  example:</para>
@@ -671,51 +601,44 @@ test: biba/high</screen>
 	<para>will set the <acronym>MAC</acronym> label of
 	  <literal>biba/equal</literal> on the &man.bge.4; interface.
 	  When using a setting similar to
-	  <literal>biba/high(low-high)</literal> the entire label
-	  should be quoted; otherwise an error will be
+	  <literal>biba/high(low-high)</literal>, the entire label
+	  should be quoted to prevent an error from being
 	  returned.</para>
 
 	<para>Each policy module which supports labeling has a tunable
 	  which may be used to disable the <acronym>MAC</acronym>
 	  label on network interfaces.  Setting the label to
 	  <option>equal</option> will have a similar effect.  Review
-	  the output from <command>sysctl</command>, the policy manual
-	  pages, or even the information found later in this chapter
-	  for those tunables.</para>
+	  the output of <command>sysctl</command>, the policy manual
+	  pages, and the information in this chapter for more
+	  information on those tunables.</para>
       </sect3>
     </sect2>
 
     <sect2>
       <title>Singlelabel or Multilabel?</title>
 
-      <para>By default the system will use the
-	<option>singlelabel</option> option.  But what does this
-	mean to the administrator?  There are several differences
-	which, in their own right, offer pros and cons to the
-	flexibility in the systems security model.</para>
-
-      <para>The <option>singlelabel</option> only permits for one
-	label, for instance <literal>biba/high</literal> to be used
-	for each subject or object.  It provides for lower
-	administration overhead but decreases the flexibility of
-	policies which support labeling.  Many administrators may
-	want to use the <option>multilabel</option> option in
-	their security policy.</para>
-
-      <para>The <option>multilabel</option> option will permit each
-	subject or object to have its own independent
-	<acronym>MAC</acronym> label in
-	place of the standard <option>singlelabel</option> option
-	which will allow only one label throughout the partition.
-	The <option>multilabel</option> and <option>single</option>
-	label options are only required for the policies which
-	implement the labeling feature, including the Biba, Lomac,
-	<acronym>MLS</acronym> and <acronym>SEBSD</acronym>
-	policies.</para>
+      <para>By default, the system will use
+	<option>singlelabel</option>.  For the administrator, there
+	are several differences which offer pros and cons to the
+	flexibility in the system's security model.</para>
 
-      <para>In many cases, the <option>multilabel</option> may not
-	need to be set at all.  Consider the following situation and
-	security model:</para>
+      <para>A security policy which uses <option>singlelabel</option>
+	only permits one label, such as <literal>biba/high</literal>,
+	to be used for each subject or object.  This provides lower
+	administration overhead, but decreases the flexibility of
+	policies which support labeling.</para>
+
+      <para><option>multilabel</option> permits each subject or object
+	to have its own independent <acronym>MAC</acronym> label.
+	The decision to use <option>multilabel</option> or
+	<option>singlelabel</option> is only required for the policies
+	which implement the labeling feature, including the Biba,
+	Lomac, and <acronym>MLS</acronym> policies.</para>
+
+      <para>In many cases, <option>multilabel</option> may not be
+	needed.  Consider the following situation and security
+	model:</para>
 
       <itemizedlist>
 	<listitem>
@@ -726,49 +649,41 @@ test: biba/high</screen>
 	<listitem>
 	  <para>This machine only requires one label,
 	    <literal>biba/high</literal>, for everything in the
-	    system.  Here the file system would not require the
-	    <option>multilabel</option> option as a single label
-	    will always be in effect.</para>
+	    system.  This file system would not require
+	    <option>multilabel</option> as a single label will always
+	    be in effect.</para>
 	</listitem>
 
 	<listitem>
 	  <para>But, this machine will be a web server and should
 	    have the web server run at <literal>biba/low</literal>
-	    to prevent write up capabilities.  The Biba policy and
-	    how it works will be discussed later, so if the previous
-	    comment was difficult to interpret just continue reading
-	    and return.  The server could use a separate partition
-	    set at <literal>biba/low</literal> for most if not all
-	    of its runtime state.  Much is lacking from this example,
-	    for instance the restrictions on data, configuration and
-	    user settings; however, this is just a quick example to
-	    prove the aforementioned point.</para>
+	    to prevent write up capabilities.  The server could
+	    use a separate partition set at
+	    <literal>biba/low</literal> for most if not all
+	    of its runtime state.</para>
 	</listitem>
       </itemizedlist>
 
       <para>If any of the non-labeling policies are to be used,
-	then the <option>multilabel</option> option would never
-	be required.  These include the
-	<literal>seeotheruids</literal>, <literal>portacl</literal>
-	and <literal>partition</literal> policies.</para>
-
-      <para>It should also be noted that using
-	<option>multilabel</option> with a partition and establishing
-	a security model based on <option>multilabel</option>
-	functionality could open the doors for higher administrative
-	overhead as everything in the file system would have a label.
-	This includes directories, files, and even device
+	<option>multilabel</option> would not be required.  These
+	include the <literal>seeotheruids</literal>,
+	<literal>portacl</literal> and <literal>partition</literal>
+	policies.</para>
+
+      <para>Using <option>multilabel</option> with a partition and
+	establishing a security model based on
+	<option>multilabel</option> functionality could increase
+	administrative overhead as everything in the file system has a
+	label.  This includes directories, files, and even device
 	nodes.</para>
 
       <para>The following command will set <option>multilabel</option>
 	on the file systems to have multiple labels.  This may only be
-	done in single user mode:</para>
+	done in single user mode and is not a requirement for the swap
+	file system:</para>
 
       <screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen>
 
-      <para>This is not a requirement for the swap file
-	system.</para>
-
       <note>
 	<para>Some users have experienced problems with setting the
 	  <option>multilabel</option> flag on the root partition.
@@ -782,20 +697,9 @@ test: biba/high</screen>
     <title>Planning the Security Configuration</title>
 
     <para>Whenever a new technology is implemented, a planning phase
-      is always a good idea.  During the planning stages, an
-      administrator should in general look at the <quote>big
-	picture</quote>, trying to keep in view at least the
-      following:</para>
-
-    <itemizedlist>
-      <listitem>
-	<para>The implementation requirements;</para>
-      </listitem>
-
-      <listitem>
-	<para>The implementation goals;</para>
-      </listitem>
-    </itemizedlist>
+      is recommended.  During the planning stages, an administrator
+      should consider the implementation requirements and the
+      implementation goals.</para>
 
     <para>For <acronym>MAC</acronym> installations, these
       include:</para>
@@ -807,8 +711,8 @@ test: biba/high</screen>
       </listitem>
 
       <listitem>
-	<para>What sorts of information or resources to restrict
-	  access to along with the type of restrictions that should be
+	<para>Which information or resources to restrict access to
+	  along with the type of restrictions that should be
 	  applied.</para>
       </listitem>
 
@@ -818,60 +722,54 @@ test: biba/high</screen>
       </listitem>
     </itemizedlist>
 
-    <para>It is always possible to reconfigure and change the
-      system resources and security settings, it is quite often very
-      inconvenient to search through the system and fix existing
-      files and user accounts.  Planning helps to ensure a
-      trouble-free and efficient trusted system implementation.  A
-      trial run of the trusted system, including the configuration,
-      is often vital and definitely beneficial
+    <para>Good planning helps to ensure a trouble-free and efficient
+      trusted system implementation.  A trial run of the trusted
+      system and its configuration should occur
       <emphasis>before</emphasis> a <acronym>MAC</acronym>
       implementation is used on production systems.  The idea of
       just letting loose on a system with <acronym>MAC</acronym> is
       like setting up for failure.</para>
 
-    <para>Different environments may have explicit needs and
+    <para>Different environments have different needs and
       requirements.  Establishing an in depth and complete security
       profile will decrease the need of changes once the system
-      goes live.  As such, the future sections will cover the
-      different modules available to administrators; describe their
-      use and configuration; and in some cases provide insight on
-      what situations they would be most suitable for.  For instance,
-      a web server might roll out the &man.mac.biba.4; and
-      &man.mac.bsdextended.4; policies.  In other cases, a machine
-      with very few local users, the &man.mac.partition.4; might
-      be a good choice.</para>
+      goes live.  The rest of this chapter covers the available
+      modules, describes their use and configuration, and in some
+      cases, provides insight on applicable situations.  For instance,
+      a web server might use the &man.mac.biba.4; and
+      &man.mac.bsdextended.4; policies.  In the case of a machine
+      with few local users, &man.mac.partition.4; might be a good
+      choice.</para>
   </sect1>
 
   <sect1 id="mac-modules">
     <title>Module Configuration</title>
 
-    <para>Every module included with the <acronym>MAC</acronym>
-      framework may be either compiled into the kernel as noted above
-      or loaded as a run-time kernel module.
-      The recommended method is to add the module name to the
-      <filename>/boot/loader.conf</filename> file so that it will load
-      during the initial boot operation.</para>
-
-    <para>The following sections will discuss the various
-      <acronym>MAC</acronym> modules and cover their features.
-      Implementing them into a specific environment will also
-      be a consideration of this chapter.  Some modules support
-      the use of labeling, which is controlling access by enforcing
-      a label such as <quote>this is allowed and this is not</quote>.
-      A label configuration file may control how files may be
-      accessed, network communication can be exchanged, and more.
-      The previous section showed how the <option>multilabel</option>
-      flag could be set on file systems to enable per-file or
-      per-partition access control.</para>
-
-    <para>A single label configuration would enforce only one label
+    <para>Beginning with &os;&nbsp;8.0, the default &os; kernel
+      includes <literal>options MAC</literal>. This means that
+      every module included with the <acronym>MAC</acronym>
+      framework may be loaded as a run-time kernel module.  The
+      recommended method is to add the module name to
+      <filename>/boot/loader.conf</filename> so that it will load
+      during boot.  Each module also provides a kernel option
+      for those administrators who choose to compile their own
+      custom kernel.</para>
+
+    <para>Some modules support the use of labeling, which is
+      controlling access by enforcing a label such as <quote>this is
+      allowed and this is not</quote>.  A label configuration file may
+      control how files may be accessed, network communication can be
+      exchanged, and more.  The previous section showed how the
+      <option>multilabel</option> flag could be set on file systems to
+      enable per-file or per-partition access control.</para>
+
+    <para>A single label configuration enforces only one label
       across the system, that is why the <command>tunefs</command>
       option is called <option>multilabel</option>.</para>
   </sect1>
 
   <sect1 id="mac-seeotheruids">
-    <title>The MAC seeotheruids Module</title>
+    <title>The &man.mac.seeotheruids.4; Module</title>
 
     <indexterm>
       <primary>MAC See Other UIDs Policy</primary>
@@ -885,8 +783,8 @@ test: biba/high</screen>
       <literal>mac_seeotheruids_load="YES"</literal></para>
 
     <para>The &man.mac.seeotheruids.4; module mimics and extends
-      the <literal>security.bsd.see_other_uids</literal> and
-      <literal>security.bsd.see_other_gids</literal>
+      the <varname>security.bsd.see_other_uids</varname> and
+      <varname>security.bsd.see_other_gids</varname>
       <command>sysctl</command> tunables.  This option does
       not require any labels to be set before configuration and
       can operate transparently with the other modules.</para>
@@ -897,37 +795,36 @@ test: biba/high</screen>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.seeotheruids.enabled</literal>
-	  will enable the module's features and use the default
-	  settings.  These default settings will deny users the
-	  ability to view processes and sockets owned by other
-	  users.</para>
+	<para><varname>security.mac.seeotheruids.enabled</varname>
+	  enables the module and uses the default settings which deny
+	  users the ability to view processes and sockets owned by
+	  other users.</para>
       </listitem>
 
       <listitem>
 	<para>
-	  <literal>security.mac.seeotheruids.specificgid_enabled</literal>
-	  will allow a certain group to be exempt from this policy.
-	  To exempt specific groups from this policy, use the
-	  <literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal>
-	  <command>sysctl</command> tunable.  In the above example,
-	  the <replaceable>XXX</replaceable> should be replaced with
-	  the numeric group ID to be exempted.</para>
+	  <varname>security.mac.seeotheruids.specificgid_enabled</varname>
+	  allows certain groups to be exempt from this policy.  To
+	  exempt specific groups from this policy, use the
+	  <varname>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></varname>
+	  <command>sysctl</command> tunable.  Replace
+	  <replaceable>XXX</replaceable> with the numeric group ID to
+	  be exempted.</para>
       </listitem>
 
       <listitem>
 	<para>
-	  <literal>security.mac.seeotheruids.primarygroup_enabled</literal>
+	  <varname>security.mac.seeotheruids.primarygroup_enabled</varname>
 	  is used to exempt specific primary groups from this policy.
-	  When using this tunable, the
-	  <literal>security.mac.seeotheruids.specificgid_enabled</literal>
+	  When using this tunable,
+	  <varname>security.mac.seeotheruids.specificgid_enabled</varname>
 	  may not be set.</para>
       </listitem>
     </itemizedlist>
   </sect1>
 
   <sect1 id="mac-bsdextended">
-    <title>The MAC bsdextended Module</title>
+    <title>The &man.mac.bsdextended.4; Module</title>
 
     <indexterm>
       <primary>MAC</primary>
@@ -950,18 +847,17 @@ test: biba/high</screen>
       rules is iterated until either a matching rule is located or
       the end is reached.  This behavior may be changed by the use
       of a &man.sysctl.8; parameter,
-      security.mac.bsdextended.firstmatch_enabled.  Similar to
-      other firewall modules in &os;, a file containing access
-      control rules can be created and read by the system at boot
-      time using an &man.rc.conf.5; variable.</para>
+      <varname>security.mac.bsdextended.firstmatch_enabled</varname>.
+      Similar to other firewall modules in &os;, a file containing
+      the access control rules can be created and read by the system
+      at boot time using an &man.rc.conf.5; variable.</para>
 
-    <para>The rule list may be entered using a utility,
-      &man.ugidfw.8;, that has a syntax similar to that of
-      &man.ipfw.8;.  More tools can be written by using the functions
-      in the &man.libugidfw.3; library.</para>
+    <para>The rule list may be entered using &man.ugidfw.8; which has
+      a syntax similar to &man.ipfw.8;.  More tools can be written by
+      using the functions in the &man.libugidfw.3; library.</para>
 
     <para>Extreme caution should be taken when working with this
-      module; incorrect use could block access to certain parts of
+      module as incorrect use could block access to certain parts of
       the file system.</para>
 
     <sect2>
@@ -974,48 +870,41 @@ test: biba/high</screen>
       <screen>&prompt.root; <userinput>ugidfw list</userinput>
 0 slots, 0 rules</screen>
 
-      <para>As expected, there are no rules defined.  This means that
-	everything is still completely accessible.  To create a rule
-	which will block all access by users but leave
-	<username>root</username> unaffected, simply run the
-	following command:</para>
+      <para>By default, no rules are defined and everything is
+	completely accessible.  To create a rule which will block all
+	access by users but leave <username>root</username>
+	unaffected, run the following command:</para>
 
       <screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen>
 
       <para>This is a very bad idea as it will block all users from
 	issuing even the most simple commands, such as
-	<command>ls</command>.  A more patriotic list of rules
-	might be:</para>
+	<command>ls</command>.  The next example will block
+	<username>user1</username> any and all access, including
+	directory listings, to
+	<username><replaceable>user2</replaceable></username>'s home
+	directory:</para>
 
       <screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput>
 &prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen>
 
-      <para>This will block any and all access, including directory
-	listings, to
-	<username><replaceable>user2</replaceable></username>'s home
-	directory from the username <username>user1</username>.</para>
-
-      <para>In place of <username>user1</username>, the
+      <para>Instead of <username>user1</username>,
 	<option>not uid <replaceable>user2</replaceable></option>
-	could be passed.  This will enforce the same access
-	restrictions above for all users in place of just one
-	user.</para>
+	could be used.  This enforces the same access restrictions for
+	all users instead of just one user.</para>
 
       <note>
-	<para>The <username>root</username> user will be unaffected
-	  by these changes.</para>
+	<para>The <username>root</username> user is unaffected by
+	  these changes.</para>
       </note>
 
-      <para>This should provide a general idea of how the
-	&man.mac.bsdextended.4; module may be used to help fortify
-	a file system.  For more information, see the
-	&man.mac.bsdextended.4; and the &man.ugidfw.8; manual
-	pages.</para>
+      <para>For more information, refer to &man.mac.bsdextended.4; and
+	&man.ugidfw.8;</para>
     </sect2>
   </sect1>
 
   <sect1 id="mac-ifoff">
-    <title>The MAC ifoff Module</title>
+    <title>The &man.mac.ifoff.4; Module</title>
 
     <indexterm>
       <primary>MAC Interface Silencing Policy</primary>
@@ -1025,33 +914,34 @@ test: biba/high</screen>
     <para>Kernel configuration line:
       <literal>options MAC_IFOFF</literal></para>
 
-    <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para>
+    <para>Boot option:
+      <literal>mac_ifoff_load="YES"</literal></para>
 
     <para>The &man.mac.ifoff.4; module exists solely to disable
       network interfaces on the fly and keep network interfaces from
-      being brought up during the initial system boot.  It does not
-      require any labels to be set up on the system, nor does it have
-      a dependency on other <acronym>MAC</acronym> modules.</para>
+      being brought up during system boot.  It does not require any
+      labels to be set up on the system, nor does it depend on other
+      <acronym>MAC</acronym> modules.</para>
 
-    <para>Most of the control is done through the
+    <para>Most of this module's control is performed through the
       <command>sysctl</command> tunables listed below.</para>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.ifoff.lo_enabled</literal> will
-	  enable/disable all traffic on the loopback (&man.lo.4;)
+	<para><varname>security.mac.ifoff.lo_enabled</varname>
+	  enables or disables all traffic on the loopback (&man.lo.4;)
 	  interface.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.ifoff.bpfrecv_enabled</literal>
-	  will enable/disable all traffic on the Berkeley Packet
+	<para><varname>security.mac.ifoff.bpfrecv_enabled</varname>
+	  enables or disables all traffic on the Berkeley Packet
 	  Filter interface (&man.bpf.4;)</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.ifoff.other_enabled</literal> will
-	  enable/disable traffic on all other interfaces.</para>
+	<para><varname>security.mac.ifoff.other_enabled</varname>
+	  enables or disables traffic on all other interfaces.</para>
       </listitem>
     </itemizedlist>
 
@@ -1065,7 +955,7 @@ test: biba/high</screen>
   </sect1>
 
   <sect1 id="mac-portacl">
-    <title>The MAC portacl Module</title>
+    <title>The &man.mac.portacl.4; Module</title>
 
     <indexterm>
       <primary>MAC Port Access Control List Policy</primary>
@@ -1080,119 +970,106 @@ test: biba/high</screen>
 
     <para>The &man.mac.portacl.4; module is used to limit binding to
       local <acronym>TCP</acronym> and <acronym>UDP</acronym> ports
-      using a variety of <command>sysctl</command> variables.  In
-      essence &man.mac.portacl.4; makes it possible to allow
+      using a variety of <command>sysctl</command> variables.
+      &man.mac.portacl.4; makes it possible to allow
       non-<username>root</username> users to bind to specified
-      privileged ports, i.e., ports below 1024.</para>
+      privileged ports below 1024.</para>
 
-    <para>Once loaded, this module will enable the
+    <para>Once loaded, this module enables the
       <acronym>MAC</acronym> policy on all sockets.  The following
       tunables are available:</para>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.portacl.enabled</literal> will
-	  enable/disable the policy completely.</para>
+	<para><varname>security.mac.portacl.enabled</varname>
+	  enables or disables the policy completely.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.portacl.port_high</literal> will
-	  set the highest port number that &man.mac.portacl.4;
-	  will enable protection for.</para>
+	<para><varname>security.mac.portacl.port_high</varname>
+	  sets the highest port number that &man.mac.portacl.4;
+	  protects.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.portacl.suser_exempt</literal>
-	  will, when set to a non-zero value, exempt the
+	<para><varname>security.mac.portacl.suser_exempt</varname>,
+	  when set to a non-zero value, exempts the
 	  <username>root</username> user from this policy.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.portacl.rules</literal> will
-	  specify the actual mac_portacl policy; see below.</para>
+	<para><varname>security.mac.portacl.rules</varname>
+	  specifies the mac_portacl policy, which is a text string of
+	  the form: <literal>rule[,rule,...]</literal> with as many
+	  rules as needed.  Each rule is of the form:
+	  <literal>idtype:id:protocol:port</literal>.  The
+	  <parameter>idtype</parameter> parameter can be
+	  <literal>uid</literal> or <literal>gid</literal> and is used
+	  to interpret the <parameter>id</parameter> parameter as
+	  either a user id or group id, respectively.  The
+	  <parameter>protocol</parameter> parameter is used to
+	  determine if the rule should apply to <acronym>TCP</acronym>
+	  or <acronym>UDP</acronym> by setting the parameter to
+	  <literal>tcp</literal> or <literal>udp</literal>.  The final
+	  <parameter>port</parameter> parameter is the port number to
+	  allow the specified user or group to bind to.</para>
       </listitem>
     </itemizedlist>
 
-    <para>The actual <literal>mac_portacl</literal> policy, as
-      specified in the <literal>security.mac.portacl.rules</literal>
-      sysctl, is a text string of the form:
-      <literal>rule[,rule,...]</literal> with as many rules as
-      needed.  Each rule is of the form:
-      <literal>idtype:id:protocol:port</literal>.  The
-      <parameter>idtype</parameter> parameter can be
-      <literal>uid</literal> or <literal>gid</literal> and used to
-      interpret the <parameter>id</parameter> parameter as either a
-      user id or group id, respectively.  The
-      <parameter>protocol</parameter> parameter is used to determine
-      if the rule should apply to <acronym>TCP</acronym> or
-      <acronym>UDP</acronym> by setting the parameter to
-      <literal>tcp</literal> or <literal>udp</literal>.  The final
-      <parameter>port</parameter> parameter is the port number to
-      allow the specified user or group to bind to.</para>
-
     <note>
-      <para>Since the ruleset is interpreted directly by the kernel
+      <para>Since the ruleset is interpreted directly by the kernel,
 	only numeric values can be used for the user ID, group ID,
-	and port parameters.  Names cannot be used for users, groups,
-	or services.</para>
+	and port parameters.  Names cannot be used for users,
+	groups, or services.</para>
     </note>
 
-    <para>By default, on &unix;-like systems, ports below 1024
-      can only be used by/bound to privileged processes,
-      i.e., those run as <username>root</username>.  For
-      &man.mac.portacl.4; to allow non-privileged processes to bind
-      to ports below 1024 this standard &unix; restriction has to
-      be disabled.  This can be accomplished by setting the
-      &man.sysctl.8; variables
-      <literal>net.inet.ip.portrange.reservedlow</literal> and
-      <literal>net.inet.ip.portrange.reservedhigh</literal>
-      to zero.</para>
+    <para>By default, ports below 1024 can only be used by or bound
+      to privileged processes, which run as
+      <username>root</username>.  For &man.mac.portacl.4; to allow
+      non-privileged processes to bind to ports below 1024, this
+      restriction has to be disabled by setting the &man.sysctl.8;
+      variables
+      <varname>net.inet.ip.portrange.reservedlow</varname> and
+      <varname>net.inet.ip.portrange.reservedhigh</varname> to
+      zero:</para>
+
+    <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
+&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0
+net.inet.ip.portrange.reservedhigh=0</userinput></screen>
 
-    <para>See the examples below or review the &man.mac.portacl.4;
-      manual page for further information.</para>
+    <para>See the examples below or refer to &man.mac.portacl.4; for
+      further information.</para>
 
     <sect2>
       <title>Examples</title>
 
-      <para>The following examples should illuminate the above
-	discussion a little better:</para>
-
-      <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
-&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0</userinput></screen>
-
-      <para>First we set &man.mac.portacl.4; to cover the standard
-	privileged ports and disable the normal &unix; bind
-	restrictions.</para>
+      <para>Since the <username>root</username> user should not be
+	crippled by this policy, this example starts by setting the
+	<varname>security.mac.portacl.suser_exempt</varname> to a
+	non-zero value.</para>
 
       <screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen>
 
-      <para>The <username>root</username> user should not be crippled
-	by this policy, thus set the
-	<literal>security.mac.portacl.suser_exempt</literal> to a
-	non-zero value.  The &man.mac.portacl.4; module
-	has now been set up to behave the same way &unix;-like systems
-	behave by default.</para>
+      <para>Next, allow the user with <acronym>UID</acronym> 80
+	to bind to port 80.  This allows the <username>www</username>
+	user to run a web server without ever having
+	<username>root</username> privilege.</para>
 
       <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen>
 
-      <para>Allow the user with <acronym>UID</acronym> 80 (normally
-	the <username>www</username> user) to bind to port 80.
-	This can be used to allow the <username>www</username>
-	user to run a web server without ever having
-	<username>root</username> privilege.</para>
+      <para>The next example permits the user with the
+	<acronym>UID</acronym> of 1001 to bind to the
+	<acronym>TCP</acronym> ports 110 (<quote>pop3</quote>) and 995
+	(<quote>pop3s</quote>).  This permits this user to start a
+	server that accepts connections on ports 110 and 995.</para>
 
       <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
 
-      <para>Permit the user with the <acronym>UID</acronym> of
-	1001 to bind to the <acronym>TCP</acronym> ports 110
-	(<quote>pop3</quote>) and 995 (<quote>pop3s</quote>).
-	This will permit this user to start a server that accepts
-	connections on ports 110 and 995.</para>
     </sect2>
   </sect1>
 
   <sect1 id="mac-partition">
-    <title>The MAC partition Module</title>
+    <title>The &man.mac.partition.4; Module</title>
 
     <indexterm>
       <primary>MAC Process Partition Policy</primary>
@@ -1207,23 +1084,18 @@ test: biba/high</screen>
 
     <para>The &man.mac.partition.4; policy will drop processes into
       specific <quote>partitions</quote> based on their
-      <acronym>MAC</acronym> label.  Think of it as a special
-      type of &man.jail.8;, though that is hardly a worthy
-      comparison.</para>
-
-    <para>This is one module that should be added to the
-      &man.loader.conf.5; file so that it loads
-      and enables the policy during the boot process.</para>
+      <acronym>MAC</acronym> label.  This module should be added to
+      &man.loader.conf.5; so that it loads and enables the policy
+      at system boot.</para>
 
     <para>Most configuration for this policy is done using
-      the &man.setpmac.8; utility which will be explained below.
-      The following <command>sysctl</command> tunable is
+      &man.setpmac.8;.  One <command>sysctl</command> tunable is
       available for this policy:</para>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.partition.enabled</literal> will
-	  enable the enforcement of <acronym>MAC</acronym> process
+	<para><varname>security.mac.partition.enabled</varname>
+	  enables the enforcement of <acronym>MAC</acronym> process
 	  partitions.</para>
       </listitem>
     </itemizedlist>
@@ -1232,32 +1104,30 @@ test: biba/high</screen>
       to see their processes, and any others within their partition,
       but will not be permitted to work with utilities outside the
       scope of this partition.  For instance, a user in the
-      <literal>insecure</literal> class above will not be permitted
-      to access the <command>top</command> command as well as many
-      other commands that must spawn a process.</para>
+      <literal>insecure</literal> class will not be permitted to
+      access <command>top</command> as well as many other commands
+      that must spawn a process.</para>
 
     <para>To set or drop utilities into a partition label, use the
       <command>setpmac</command> utility:</para>
 
     <screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
 
-    <para>This will add the <command>top</command> command to the
-      label set on users in the <literal>insecure</literal> class.
-      Note that all processes spawned by users
-      in the <literal>insecure</literal> class will stay in the
-      <literal>partition/13</literal> label.</para>
+    <para>This example adds <command>top</command> to the label set on
+      users in the <literal>insecure</literal> class.  All processes
+      spawned by users in the <literal>insecure</literal> class will
+      stay in the <literal>partition/13</literal> label.</para>
 
     <sect2>
       <title>Examples</title>
 
-      <para>The following command will show you the partition label
+      <para>The following command will display the partition label
 	and the process list:</para>
 
       <screen>&prompt.root; <userinput>ps Zax</userinput></screen>
 
-      <para>This next command will allow the viewing of another
-	user's process partition label and that user's currently
-	running processes:</para>
+      <para>This command will display another user's process partition
+	label and that user's currently running processes:</para>
 
       <screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen>
 
@@ -1299,13 +1169,13 @@ test: biba/high</screen>
       flow policy.</para>
 
     <para>In <acronym>MLS</acronym> environments, a
-      <quote>clearance</quote> level is set in each subject or objects
-      label, along with compartments.  Since these clearance or
-      sensibility levels can reach numbers greater than six thousand;
-      it would be a daunting task for any system administrator to
-      thoroughly configure each subject or object.  Thankfully, three
-      <quote>instant</quote> labels are already included in this
-      policy.</para>
+      <quote>clearance</quote> level is set in the label of each
+      subject or object, along with compartments.  Since these
+      clearance or sensibility levels can reach numbers greater than
+      several thousand; it would be a daunting task for any system
+      administrator to thoroughly configure each subject or object.
+      Thankfully, three <quote>instant</quote> labels are included in
+      this policy.</para>
 
     <para>These labels are <literal>mls/low</literal>,
       <literal>mls/equal</literal> and <literal>mls/high</literal>.
@@ -1318,9 +1188,9 @@ test: biba/high</screen>
 	  configuration which permits it to be dominated by all other
 	  objects.  Anything labeled with <literal>mls/low</literal>
 	  will have a low clearance level and not be permitted to
-	  access information of a higher level.  In addition, this
-	  label will prevent objects of a higher clearance level from
-	  writing or passing information on to them.</para>
+	  access information of a higher level.  This label also
+	  prevents objects of a higher clearance level from writing or
+	  passing information on to them.</para>
       </listitem>
 
       <listitem>
@@ -1338,30 +1208,31 @@ test: biba/high</screen>
       </listitem>
     </itemizedlist>
 
-    <para><acronym>MLS</acronym> provides for:</para>
+    <para><acronym>MLS</acronym> provides:</para>
 
     <itemizedlist>
       <listitem>
 	<para>A hierarchical security level with a set of non
-	  hierarchical categories;</para>
+	  hierarchical categories.</para>
       </listitem>
 
       <listitem>
-	<para>Fixed rules: no read up, no write down (a subject can
-	  have read access to objects on its own level or below, but
-	  not above.  Similarly, a subject can have write access to
-	  objects on its own level or above but not beneath.);</para>
+	<para>Fixed rules of <literal>no read up, no write
+	    down</literal>.  This means that a subject can have read
+	  access to objects on its own level or below, but not above.
+	  Similarly, a subject can have write access to objects on its
+	  own level or above but not beneath.</para>
       </listitem>
 
       <listitem>
-	<para>Secrecy (preventing inappropriate disclosure
-	  of data);</para>
+	<para>Secrecy, or the prevention of inappropriate disclosure
+	  of data.</para>
       </listitem>
 
       <listitem>
-	<para>Basis for the design of systems that concurrently handle
-	  data at multiple sensitivity levels (without leaking
-	  information between secret and confidential).</para>
+	<para>A basis for the design of systems that concurrently
+	  handle data at multiple sensitivity levels without leaking
+	  information between secret and confidential.</para>
       </listitem>
     </itemizedlist>
 
@@ -1371,77 +1242,71 @@ test: biba/high</screen>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.mls.enabled</literal> is used to
-	  enable/disable the <acronym>MLS</acronym> policy.</para>
+	<para><varname>security.mac.mls.enabled</varname> is used to
+	  enable or disable the <acronym>MLS</acronym> policy.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.mls.ptys_equal</literal> will
-	  label all &man.pty.4; devices as
+	<para><varname>security.mac.mls.ptys_equal</varname>
+	  labels all &man.pty.4; devices as
 	  <literal>mls/equal</literal> during creation.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.mls.revocation_enabled</literal>
-	  is used to revoke access to objects after their label
-	  changes to a label of a lower grade.</para>
+	<para><varname>security.mac.mls.revocation_enabled</varname>
+	  revokes access to objects after their label changes to a
+	  label of a lower grade.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.mls.max_compartments</literal>
-	  is used to set the maximum number of compartment levels
-	  with objects; basically the maximum compartment number
-	  allowed on a system.</para>
+	<para><varname>security.mac.mls.max_compartments</varname>
+	  sets the maximum number of compartment levels allowed on a
+	  system.</para>
       </listitem>
     </itemizedlist>
 
-    <para>To manipulate the <acronym>MLS</acronym> labels, the
-      &man.setfmac.8; command has been provided.  To assign a label
-      to an object, issue the following command:</para>
+    <para>To manipulate the <acronym>MLS</acronym> labels, use
+      &man.setfmac.8;.  To assign a label to an object, issue the
+      following command:</para>
 
     <screen>&prompt.root; <userinput>setfmac mls/5 test</userinput></screen>
 
     <para>To get the <acronym>MLS</acronym> label for the file
-      <filename>test</filename> issue the following command:</para>
+      <filename>test</filename>, issue the following command:</para>
 
     <screen>&prompt.root; <userinput>getfmac test</userinput></screen>
 
-    <para>This is a summary of the <acronym>MLS</acronym>
-      policy's features.  Another approach is to create a master
-      policy file in <filename class="directory">/etc</filename>
-      which specifies the <acronym>MLS</acronym> policy information
-      and to feed that file into the <command>setfmac</command>
-      command.  This method will be explained after all policies are
-      covered.</para>
+    <para>Another approach is to create a master policy file in
+      <filename class="directory">/etc/</filename> which specifies the
+      <acronym>MLS</acronym> policy information and to feed that file
+      to <command>setfmac</command>.  This method will be explained
+      after all policies are covered.</para>
 
     <sect2>
       <title>Planning Mandatory Sensitivity</title>
 
-      <para>With the Multi-Level Security Policy Module, an
-	administrator plans for controlling the flow of sensitive
-	information.  By default, with its block read up block write
-	down nature, the system defaults everything to a low state.
-	Everything is accessible and an administrator
-	slowly changes this during the configuration stage; augmenting
-	the confidentiality of the information.</para>
-
-      <para>Beyond the three basic label options above, an
-	administrator may group users and groups as required to block
-	the information flow between them.  It might be easier to
-	look at the information in clearance levels familiarized with
-	words, for instance classifications such as
-	<literal>Confidential</literal>, <literal>Secret</literal>,
-	and <literal>Top Secret</literal>.  Some administrators might
-	just create different groups based on project levels.
-	Regardless of classification method, a well thought out plan
-	must exist before implementing such a restrictive
-	policy.</para>
-
-      <para>Some example situations for this security policy module
-	could be an e-commerce web server, a file server holding
+      <para>When using the MLS policy module, an administrator plans
+	to control the flow of sensitive information.  The default
+	<literal>block read up block write down</literal> sets
+	everything to a low state.  Everything is accessible and an
+	administrator slowly augments the confidentiality of the
+	information during the configuration stage;.</para>
+
+      <para>Beyond the three basic label options, an administrator may
+	group users and groups as required to block the information
+	flow between them.  It might be easier to look at the
+	information in clearance levels using descriptive words, such
+	as classifications of <literal>Confidential</literal>,
+	<literal>Secret</literal>, and <literal>Top Secret</literal>.
+	Some administrators instead create different groups based on
+	project levels.  Regardless of the classification method, a
+	well thought out plan must exist before implementing such a
+	restrictive policy.</para>
+
+      <para>Some example situations for the MLS policy module
+	include an e-commerce web server, a file server holding
 	critical company information, and financial institution
-	environments.  The most unlikely place would be a personal
-	workstation with only two or three users.</para>
+	environments.</para>
     </sect2>
   </sect1>
 
@@ -1453,25 +1318,24 @@ test: biba/high</screen>
     </indexterm>
     <para>Module name: <filename>mac_biba.ko</filename></para>
 
-    <para>Kernel configuration line:
-      <literal>options MAC_BIBA</literal></para>
+    <para>Kernel configuration line: <literal>options
+	MAC_BIBA</literal></para>
 
     <para>Boot option: <literal>mac_biba_load="YES"</literal></para>
 
     <para>The &man.mac.biba.4; module loads the <acronym>MAC</acronym>
-      Biba policy.  This policy works much like that of the
+      Biba policy.  This policy is similar to the
       <acronym>MLS</acronym> policy with the exception that the rules
-      for information flow
-      are slightly reversed.  This is said to prevent the downward
-      flow of sensitive information whereas the <acronym>MLS</acronym>
-      policy prevents the upward flow of sensitive information; thus,
-      much of this section can apply to both policies.</para>
+      for information flow are slightly reversed.  This is to prevent
+      the downward flow of sensitive information whereas the
+      <acronym>MLS</acronym> policy prevents the upward flow of
+      sensitive information.  Much of this section can apply to both
+      policies.</para>
 
     <para>In Biba environments, an <quote>integrity</quote> label is
       set on each subject or object.  These labels are made up of
-      hierarchal grades, and non-hierarchal components.  As an
-      object's or subject's grade ascends, so does its
-      integrity.</para>
+      hierarchical grades and non-hierarchical components.  As an
+      grade ascends, so does its integrity.</para>
 
     <para>Supported labels are <literal>biba/low</literal>,
       <literal>biba/equal</literal>, and <literal>biba/high</literal>;
@@ -1501,59 +1365,60 @@ test: biba/high</screen>
       </listitem>
     </itemizedlist>
 
-    <para>Biba provides for:</para>
+    <para>Biba provides:</para>
 
     <itemizedlist>
       <listitem>
 	<para>Hierarchical integrity level with a set of non
-	  hierarchical integrity categories;</para>
+	  hierarchical integrity categories.</para>
       </listitem>
 
       <listitem>
-	<para>Fixed rules: no write up, no read down (opposite of
-	  <acronym>MLS</acronym>).  A subject can have write access
+	<para>Fixed rules are <literal>no write up, no read
+	    down</literal>, the opposite of
+	  <acronym>MLS</acronym>.  A subject can have write access
 	  to objects on its own level or below, but not above.
 	  Similarly, a subject can have read access to objects on
-	  its own level or above, but not below;</para>
+	  its own level or above, but not below.</para>
       </listitem>
 
       <listitem>
-	<para>Integrity (preventing inappropriate modification of
-	  data);</para>
+	<para>Integrity by preventing inappropriate modification of
+	  data.</para>
       </listitem>
 
       <listitem>
-	<para>Integrity levels (instead of MLS sensitivity
-	  levels).</para>
+	<para>Integrity levels instead of MLS sensitivity
+	  levels.</para>
       </listitem>
     </itemizedlist>
 
     <para>The following <command>sysctl</command> tunables can
-      be used to manipulate the Biba policy.</para>
+      be used to manipulate the Biba policy:</para>
 
     <itemizedlist>
       <listitem>
-	<para><literal>security.mac.biba.enabled</literal> may be used
-	  to enable/disable enforcement of the Biba policy on the
+	<para><varname>security.mac.biba.enabled</varname> is used
+	  to enable or disable enforcement of the Biba policy on the
 	  target machine.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.biba.ptys_equal</literal> may be
+	<para><varname>security.mac.biba.ptys_equal</varname> is
 	  used to disable the Biba policy on &man.pty.4;
 	  devices.</para>
       </listitem>
 
       <listitem>
-	<para><literal>security.mac.biba.revocation_enabled</literal>
-	  will force the revocation of access to objects if the label
+	<para><varname>security.mac.biba.revocation_enabled</varname>
+	  forces the revocation of access to objects if the label
 	  is changed to dominate the subject.</para>
       </listitem>
     </itemizedlist>
 
     <para>To access the Biba policy setting on system objects, use
-      the <command>setfmac</command> and <command>getfmac</command>
-      commands:</para>
+      <command>setfmac</command> and
+      <command>getfmac</command>:</para>
 
     <screen>&prompt.root; <userinput>setfmac biba/low test</userinput>
 &prompt.root; <userinput>getfmac test</userinput>
@@ -1562,44 +1427,41 @@ test: biba/low</screen>
     <sect2>
       <title>Planning Mandatory Integrity</title>
 
-      <para>Integrity, different from sensitivity, guarantees that the
-	information will never be manipulated by untrusted parties.
-	This includes information passed between subjects, objects,
-	and both.  It ensures that users will only be able to modify
-	and in some cases even access information they explicitly need
-	to.</para>
+      <para>Integrity, which is different from sensitivity, guarantees
+	that the information will never be manipulated by untrusted
+	parties.  This includes information passed between subjects,
+	objects, and both.  It ensures that users will only be able to
+	modify or access information they explicitly need to.</para>
 
       <para>The &man.mac.biba.4; security policy module permits an
-	administrator to address which files and programs a user or
-	users may see and invoke while assuring that the programs and
-	files are free from threats and trusted by the system for that
-	user, or group of users.</para>
+	administrator to address which files and programs a user may
+	see and invoke while assuring that the programs and files are
+	free from threats and trusted by the system for that
+	user.</para>
 
       <para>During the initial planning phase, an administrator must
 	be prepared to partition users into grades, levels, and areas.
-	Users will be blocked access not only to data but programs
+	Users will be blocked access not only to data but to programs
 	and utilities both before and after they start.  The system
 	will default to a high label once this policy module is
 	enabled, and it is up to the administrator to configure the
 	different grades and levels for users.  Instead of using
-	clearance levels as described above, a good planning method
-	could include topics.  For instance, only allow developers
-	modification access to the source code repository, source
-	code compiler, and other development utilities.  While other
-	users would be grouped into other categories such as testers,
-	designers, or just ordinary users and would only be permitted
-	read access.</para>
-
-      <para>With its natural security control, a lower integrity
-	subject is unable to write to a higher integrity subject; a
-	higher integrity subject cannot observe or read a lower
-	integrity object.  Setting a label at the lowest possible
-	grade could make it inaccessible to subjects.  Some
-	prospective environments for this security policy module
-	would include a constrained web server, development and test
-	machine, and source code repository.  A less useful
-	implementation would be a personal workstation, a machine
-	used as a router, or a network firewall.</para>
+	clearance levels, a good planning method could include topics.
+	For instance, only allow developers modification access to the
+	source code repository, source code compiler, and other
+	development utilities.  Other users would be grouped into
+	other categories such as testers, designers, or end users and
+	would only be permitted read access.</para>
+
+      <para>A lower integrity subject is unable to write to a higher
+	integrity subject and a higher integrity subject cannot
+	observe or read a lower integrity object.  Setting a label at
+	the lowest possible grade could make it inaccessible to
+	subjects.  Some prospective environments for this security
+	policy module would include a constrained web server, a
+	development and test machine, and a source code repository.  A
+	less useful implementation would be a personal workstation, a
+	machine used as a router, or a network firewall.</para>
     </sect2>
   </sect1>
 
@@ -1611,8 +1473,9 @@ test: biba/low</screen>
     </indexterm>
     <para>Module name: <filename>mac_lomac.ko</filename></para>
 
-    <para>Kernel configuration line:
-      <literal>options MAC_LOMAC</literal></para>
+    <para>Kernel configuration line: <literal>options
+	MAC_LOMAC</literal></para>
+
     <para>Boot option: <literal>mac_lomac_load="YES"</literal></para>
 
     <para>Unlike the <acronym>MAC</acronym> Biba policy, the
@@ -1621,13 +1484,11 @@ test: biba/low</screen>
       any integrity rules.</para>
 
     <para>The <acronym>MAC</acronym> version of the Low-watermark
-      integrity policy, not to be confused with the older
-      &man.lomac.4; implementation, works almost identically to Biba,
-      but with the exception of using floating labels to support
-      subject demotion via an auxiliary grade compartment.  This
-      secondary compartment takes the form of
-      <literal>[auxgrade]</literal>.  When assigning a lomac policy
-      with an auxiliary grade, it should look a little bit like:
+      integrity policy works almost identically to Biba, but with the
+      exception of using floating labels to support subject demotion
+      via an auxiliary grade compartment.  This secondary compartment
+      takes the form <literal>[auxgrade]</literal>.  When assigning
+      a LOMAC policy with an auxiliary grade, use the syntax
       <literal>lomac/10[2]</literal> where the number two (2) is the
       auxiliary grade.</para>
 
@@ -1635,25 +1496,23 @@ test: biba/low</screen>
       ubiquitous labeling of all system objects with integrity labels,
       permitting subjects to read from low integrity objects and then
       downgrading the label on the subject to prevent future writes to
-      high integrity objects.  This is the
-      <literal>[auxgrade]</literal> option discussed above, thus the
+      high integrity objects using <literal>[auxgrade]</literal>.  The
       policy may provide for greater compatibility and require less
       initial configuration than Biba.</para>
 
     <sect2>
       <title>Examples</title>
 
-      <para>Like the Biba and <acronym>MLS</acronym> policies;
-	the <command>setfmac</command> and <command>setpmac</command>
-	utilities may be used to place labels on system
-	objects:</para>
+      <para>Like the Biba and <acronym>MLS</acronym> policies,
+	<command>setfmac</command> and <command>setpmac</command>
+	are used to place labels on system objects:</para>
 
       <screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput>
 &prompt.root; <userinput>getfmac /usr/home/trhodes</userinput> lomac/high[low]</screen>
 
-      <para>Notice the auxiliary grade here is <literal>low</literal>,
-	this is a feature provided only by the <acronym>MAC</acronym>
-	LOMAC policy.</para>
+      <para>The auxiliary grade <literal>low</literal> is a feature
+	provided only by the <acronym>MAC</acronym> LOMAC
+	policy.</para>
     </sect2>
   </sect1>
 
@@ -1664,28 +1523,25 @@ test: biba/low</screen>
       <primary>Nagios in a MAC Jail</primary>
     </indexterm>
 
-    <para>The following demonstration will implement a secure
+    <para>The following demonstration implements a secure
       environment using various <acronym>MAC</acronym> modules
-      with properly configured policies.  This is only a test and
-      should not be considered the complete answer to everyone's
-      security woes.  Just implementing a policy and ignoring it
-      never works and could be disastrous in a production
-      environment.</para>
-
-    <para>Before beginning this process, the
-      <literal>multilabel</literal> option must be set on each file
-      system as stated at the beginning of this chapter.  Not doing
-      so will result in errors.  While at it, ensure that the
-      <filename role="package">net-mngt/nagios-plugins</filename>,
+      with properly configured policies.  This is only a test as
+      implementing a policy and ignoring it could be disastrous in a
+      production environment.</para>
+
+    <para>Before beginning this process, <option>multilabel</option>
+      must be set on each file system as not doing so will result in
+      errors.  This example assumes that <filename
+	role="package">net-mngt/nagios-plugins</filename>,
       <filename role="package">net-mngt/nagios</filename>, and
-      <filename role="package">www/apache22</filename> ports are all
+      <filename role="package">www/apache22</filename> are all
       installed, configured, and working correctly.</para>
 
     <sect2>
-      <title>Create an insecure User Class</title>
+      <title>Create an Insecure User Class</title>
 
       <para>Begin the procedure by adding the following user class
-	to the <filename>/etc/login.conf</filename> file:</para>
+	to <filename>/etc/login.conf</filename>:</para>
 
       <programlisting>insecure:\
 :copyright=/etc/COPYRIGHT:\
@@ -1711,13 +1567,12 @@ test: biba/low</screen>
 :ignoretime@:\
 :label=biba/10(10-10):</programlisting>
 
-      <para>And adding the following line to the default user
-	class:</para>
+      <para>Add the following line to the default user class:</para>
 
       <programlisting>:label=biba/high:</programlisting>
 
-      <para>Once this is completed, the following command must be
-	issued to rebuild the database:</para>
+      <para>Next, issue the following command to rebuild the
+	database:</para>
 
       <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
     </sect2>
@@ -1725,9 +1580,8 @@ test: biba/low</screen>
     <sect2>
       <title>Boot Configuration</title>
 
-      <para>Do not reboot yet, just add the following lines to
-	<filename>/boot/loader.conf</filename> so the required
-	modules will load during system initialization:</para>
+      <para>Add the following lines to
+	<filename>/boot/loader.conf</filename>:</para>
 
       <programlisting>mac_biba_load="YES"
 mac_seeotheruids_load="YES"</programlisting>
@@ -1744,9 +1598,8 @@ mac_seeotheruids_load="YES"</programlisting>
       <para>All user accounts that are not <username>root</username>
 	or system users will now require a login class.  The login
 	class is required otherwise users will be refused access
-	to common commands such as &man.vi.1;.
-	The following <command>sh</command> script should do the
-	trick:</para>
+	to common commands such as &man.vi.1;.  The following
+	<command>sh</command> script should do the trick:</para>
 
       <screen>&prompt.root; <userinput>for x in `awk -F: '($3 &gt;= 1001) &amp;&amp; ($3 != 65534) { print $1 }' \</userinput>
 	<userinput>/etc/passwd`; do pw usermod $x -L default; done;</userinput></screen>
@@ -1763,8 +1616,7 @@ mac_seeotheruids_load="YES"</programlisting>
       <sect2>
 	<title>Create the Contexts File</title>
 
-	<para>A contexts file should now be created; the following
-	  example file should be placed in
+	<para>A contexts file should now be created as
 	  <filename>/etc/policy.contexts</filename>.</para>
 
 	<programlisting># This is the default BIBA policy for this system.
@@ -1802,28 +1654,28 @@ mac_seeotheruids_load="YES"</programlisting>
 /usr/local/etc/apache           biba/10
 /usr/local/etc/apache/*         biba/10</programlisting>
 
-      <para>This policy will enforce security by setting restrictions
+      <para>This policy enforces security by setting restrictions
 	on the flow of information.  In this specific configuration,
-	users, <username>root</username> and others, should never be
+	users, including <username>root</username>, should never be
 	allowed to access <application>Nagios</application>.
 	Configuration files and processes that are a part of
 	<application>Nagios</application> will be completely self
 	contained or jailed.</para>
 
-      <para>This file may now be read into our system by issuing the
+      <para>This file will be read by the system by issuing the
 	following command:</para>
 
       <screen>&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput>
 &prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput></screen>
 
       <note>
-	<para>The above file system layout may be different depending
-	  on environment; however, it must be run on every single file
+	<para>The above file system layout will differ depending
+	  upon the environment and must be run on every file
 	  system.</para>
       </note>
 
-      <para>The <filename>/etc/mac.conf</filename> file requires
-	the following modifications in the main section:</para>
+      <para><filename>/etc/mac.conf</filename> requires the following
+	modifications in the main section:</para>
 
       <programlisting>default_labels file ?biba
 default_labels ifnet ?biba
@@ -1855,45 +1707,43 @@ default_labels socket ?biba</programlisting>
       </indexterm>
 
       <para>Ensure that the web server and
-	<application>Nagios</application> will not be started
-	on system initialization, and reboot.  Ensure the
+	<application>Nagios</application> will not be started on
+	system initialization and reboot.  Ensure the
 	<username>root</username> user cannot access any of the files
 	in the <application>Nagios</application> configuration
 	directory.  If <username>root</username> can issue an
 	&man.ls.1; command on <filename>/var/spool/nagios</filename>,
-	then something is wrong.  Otherwise a <quote>permission
+	something is wrong.  Otherwise a <quote>permission
 	  denied</quote> error should be returned.</para>
 
       <para>If all seems well, <application>Nagios</application>,
 	<application>Apache</application>, and
-	<application>Sendmail</application> can now be started in a
-	way fitting of the security policy.  The following commands
-	will make this happen:</para>
+	<application>Sendmail</application> can now be started:</para>
 
       <screen>&prompt.root; <userinput>cd /etc/mail &amp;&amp; make stop &amp;&amp; \
 setpmac biba/equal make start &amp;&amp; setpmac biba/10\(10-10\) apachectl start &amp;&amp; \
 setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></screen>
 
       <para>Double check to ensure that everything is working
-	properly.  If not, check the log files or error messages.  Use
-	the &man.sysctl.8; utility to disable the &man.mac.biba.4;
-	security policy module enforcement and try starting everything
-	again, like normal.</para>
+	properly.  If not, check the log files for error messages.
+	Use &man.sysctl.8; to disable the &man.mac.biba.4; security
+	policy module enforcement and try starting everything again as
+	usual.</para>
 
       <note>
-	<para>The <username>root</username> user can change the
-	  security enforcement and edit the configuration files
-	  without fear.  The following command will permit the
-	  degradation of the security policy to a lower grade for a
-	  newly spawned shell:</para>
+	<para>The <username>root</username> user can still change the
+	  security enforcement and edit its configuration files.  The
+	  following command will permit the degradation of the
+	  security policy to a lower grade for a newly spawned
+	  shell:</para>
 
 	<screen>&prompt.root; <userinput>setpmac biba/10 csh</userinput></screen>
 
 	<para>To block this from happening, force the user into a
-	  range via &man.login.conf.5;.  If &man.setpmac.8; attempts
+	  range using &man.login.conf.5;.  If &man.setpmac.8; attempts
 	  to run a command outside of the compartment's range, an
 	  error will be returned and the command will not be executed.
-	  In this case, setting root to
+	  In this case, set root to
 	  <literal>biba/high(high-high)</literal>.</para>
       </note>
     </sect2>
@@ -1902,15 +1752,14 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
   <sect1 id="mac-userlocked">
     <title>User Lock Down</title>
 
-    <para>This example considers a relatively small, fewer than fifty
-      users, storage system.  Users would have login capabilities,
-      and be permitted to not only store data but access resources
-      as well.</para>
+    <para>This example considers a relatively small storage system
+      with fewer than fifty users.  Users will have login
+      capabilities, and be permitted to store data and access
+      resources.</para>
 
-    <para>For this scenario, the &man.mac.bsdextended.4; mixed with
-      &man.mac.seeotheruids.4; could co-exist and block access not
-      only to system objects, but to hide user processes as
-      well.</para>
+    <para>For this scenario, the &man.mac.bsdextended.4; and
+      &man.mac.seeotheruids.4; policy modules could co-exist and block
+      access to system objects while hiding user processes.</para>
 
     <para>Begin by adding the following line to
       <filename>/boot/loader.conf</filename>:</para>
@@ -1918,25 +1767,24 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
     <programlisting>mac_seeotheruids_load="YES"</programlisting>
 
     <para>The &man.mac.bsdextended.4; security policy module may be
-      activated through the use of the following rc.conf
-      variable:</para>
+      activated by adding this line to
+      <filename>/etc/rc.conf</filename>:</para>
 
     <programlisting>ugidfw_enable="YES"</programlisting>
 
     <para>Default rules stored in
       <filename>/etc/rc.bsdextended</filename> will be loaded at
-      system initialization; however, the default entries may need
+      system initialization.  However, the default entries may need
       modification.  Since this machine is expected only to service
       users, everything may be left commented out except the last
-      two.  These will force the loading of user owned system objects
-      by default.</para>
+      two lines in order to force the loading of user owned system
+      objects by default.</para>
 
     <para>Add the required users to this machine and reboot.  For
       testing purposes, try logging in as a different user across
-      two consoles.  Run the <command>ps aux</command> command to
-      see if processes of other users are visible.  Try to run
-      &man.ls.1; on another users home directory, it should
-      fail.</para>
+      two consoles.  Run <command>ps aux</command> to see if processes
+      of other users are visible.  Verify that running &man.ls.1; on
+      another user's home directory fails.</para>
 
     <para>Do not try to test with the <username>root</username> user
       unless the specific <command>sysctl</command>s have been
@@ -1945,9 +1793,8 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
     <note>
       <para>When a new user is added, their &man.mac.bsdextended.4;
 	rule will not be in the ruleset list.  To update the ruleset
-	quickly, simply unload the security policy module and reload
-	it again using the &man.kldunload.8; and &man.kldload.8;
-	utilities.</para>
+	quickly, unload the security policy module and reload it again
+	using &man.kldunload.8; and &man.kldload.8;.</para>
     </note>
   </sect1>
 
@@ -1958,30 +1805,23 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
       <primary>MAC Troubleshooting</primary>
     </indexterm>
 
-    <para>During the development stage, a few users reported problems
-      with normal configuration.  Some of these problems
-      are listed below:</para>
+    <para>This section discusses common configuration issues.</para>
 
     <sect2>
-      <title>The <option>multilabel</option> option cannot be enabled
-	on <filename>/</filename></title>
+      <title><option>multilabel</option> cannot be enabled on
+	<filename>/</filename></title>
 
-      <para>The <option>multilabel</option> flag does not stay
+      <para>The<option>multilabel</option> flag does not stay
 	enabled on my root (<filename>/</filename>) partition!</para>
 
 
-      <para>It seems that one out of every fifty users has this
-	problem, indeed, we had this problem during our initial
-	configuration.  Further observation of this so called
-	<quote>bug</quote> has lead me to believe that it is a
-	result of either incorrect documentation or misinterpretation
-	of the documentation.  Regardless of why it happened, the
-	following steps may be taken to resolve it:</para>
+      <para>The following steps may resolve this transient
+	error:</para>
 
       <procedure>
 	<step>
 	  <para>Edit <filename>/etc/fstab</filename> and set the root
-	    partition at <option>ro</option> for read-only.</para>
+	    partition to <option>ro</option> for read-only.</para>
 	</step>
 
 	<step>
@@ -1995,7 +1835,7 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
 	</step>
 
 	<step>
-	  <para>Reboot the system into normal mode.</para>
+	  <para>Reboot the system.</para>
 	</step>
 
 	<step>
@@ -2007,7 +1847,7 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
 	</step>
 
 	<step>
-	  <para>Double-check the output from the
+	  <para>Double-check the output from
 	    <command>mount</command> to ensure that
 	    <option>multilabel</option> has been properly set on the
 	    root file system.</para>
@@ -2016,12 +1856,12 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
     </sect2>
 
     <sect2>
-      <title>X11 Server Will Not Start After
+      <title>Xorg Server Will Not Start After
 	<acronym>MAC</acronym></title>
 
       <para>After establishing a secure environment with
 	<acronym>MAC</acronym>, I am no longer able to start
-	X!</para>
+	Xorg!</para>
 
       <para>This could be caused by the <acronym>MAC</acronym>
 	<literal>partition</literal> policy or by a mislabeling in
@@ -2035,25 +1875,21 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
 	    <literal>partition</literal> policy may be the culprit.
 	    Try setting the user's class back to the
 	    <literal>default</literal> class and rebuild the database
-	    with the <command>cap_mkdb</command> command.  If this
-	    does not alleviate the problem, go to step two.</para>
+	    with <command>cap_mkdb</command>.  If this does not
+	    alleviate the problem, go to step two.</para>
 	</step>
 
 	<step>
 	  <para>Double-check the label policies.  Ensure that the
-	    policies are set correctly for the user in question, the
-	    X11 application, and
-	    the <filename class="directory">/dev</filename>
-	    entries.</para>
+	    policies are set correctly for the user, the Xorg
+	    application, and the <filename
+	      class="directory">/dev</filename> entries.</para>
 	</step>
 
 	<step>
 	  <para>If neither of these resolve the problem, send the
-	    error message and a description of your environment to
-	    the TrustedBSD discussion lists located at the
-	    <ulink url="http://www.TrustedBSD.org">TrustedBSD</ulink>
-	    website or to the &a.questions;
-	    mailing list.</para>
+	    error message and a description of the environment to
+	    the &a.questions; mailing list.</para>
 	</step>
       </procedure>
     </sect2>
@@ -2062,52 +1898,50 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
       <title>Error: &man..secure.path.3; cannot stat
 	<filename>.login_conf</filename></title>
 
-      <para>When I attempt to switch from the
+      <para>When a user attempts to switch from the
 	<username>root</username> user to another user in the system,
 	the error message <errorname>_secure_path: unable to state
 	  .login_conf</errorname> appears.</para>
 
       <para>This message is usually shown when the user has a higher
-	label setting then that of the user whom they are attempting
-	to become.  For instance a user on the system,
-	<username>joe</username>, has a default label of
-	<option>biba/low</option>.  The <username>root</username>
-	user, who has a label of <option>biba/high</option>, cannot
-	view <username>joe</username>'s home directory.  This will
-	happen regardless if <username>root</username> has used the
-	<command>su</command> command to become
-	<username>joe</username>, or not.  In this scenario, the Biba
-	integrity model will not permit <username>root</username> to
-	view objects set at a lower integrity level.</para>
+	label setting than that of the user they are attempting to
+	become.  For instance, <username>joe</username> has a default
+	label of <option>biba/low</option>.  The
+	<username>root</username> user, who has a label of
+	<option>biba/high</option>, cannot view
+	<username>joe</username>'s home directory.  This will happen
+	whether or not <username>root</username> has used
+	<command>su</command> to become <username>joe</username> as
+	the Biba integrity model will not permit
+	<username>root</username> to view objects set at a lower
+	integrity level.</para>
     </sect2>
 
     <sect2>
       <title>The <username>root</username> username is broken!</title>
 
       <para>In normal or even single user mode, the
-	<username>root</username> is not recognized.  The
-	<command>whoami</command> command returns 0 (zero) and
+	<username>root</username> is not recognized,
+	<command>whoami</command> returns 0 (zero), and
 	<command>su</command> returns <errorname>who are
-	  you?</errorname>. What could be going on?</para>
+	  you?</errorname>.</para>
 
       <para>This can happen if a labeling policy has been disabled,
 	either by a &man.sysctl.8; or the policy module was unloaded.
-	If the policy is being disabled or has been temporarily
-	disabled, then the login capabilities database needs to be
-	reconfigured with the <option>label</option> option being
-	removed.  Double check the <filename>login.conf</filename>
-	file to ensure that all <option>label</option> options have
-	been removed and rebuild the database with the
-	<command>cap_mkdb</command> command.</para>
-
-      <para>This may also happen if a policy restricts access to the
-	<filename>master.passwd</filename> file or database.  Usually
-	caused by an administrator altering the file under a label
-	which conflicts with the general policy being used by the
-	system.  In these cases, the user information would be read
-	by the system and access would be blocked as the file has
-	inherited the new label.  Disable the policy via a
-	&man.sysctl.8; and everything should return to normal.</para>
+	If the policy is disabled, the login capabilities database
+	needs to be reconfigured with <option>label</option> removed.
+	Double check <filename>login.conf</filename> to ensure that
+	all <option>label</option> options have been removed and
+	rebuild the database with <command>cap_mkdb</command>.</para>
+
+      <para>This may also happen if a policy restricts access to
+	<filename>master.passwd</filename>.  This is usually caused by
+	an administrator altering the file under a label which
+	conflicts with the general policy being used by the system.
+	In these cases, the user information would be read by the
+	system and access would be blocked as the file has inherited
+	the new label.  Disable the policy using &man.sysctl.8; and
+	everything should return to normal.</para>
     </sect2>
   </sect1>
 </chapter>