svn commit: r40904 - head/en_US.ISO8859-1/books/handbook/mac

Dru Lavigne dru at FreeBSD.org
Thu Feb 7 15:05:38 UTC 2013


Author: dru
Date: Thu Feb  7 15:05:37 2013
New Revision: 40904
URL: http://svnweb.freebsd.org/changeset/doc/40904

Log:
  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)

Modified:
  head/en_US.ISO8859-1/books/handbook/mac/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/mac/chapter.xml	Thu Feb  7 15:02:30 2013	(r40903)
+++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml	Thu Feb  7 15:05:37 2013	(r40904)
@@ -27,44 +27,42 @@
     </indexterm>
 
     <para>&os; 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>
-
-	  <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>
+	    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>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>In many cases, the <option>multilabel</option> may not
-	need to be set at all.  Consider the following situation and
-	security model:</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>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

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***


More information about the svn-doc-all mailing list