Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v
retrieving revision 1.122
diff -u -r1.122 chapter.sgml
--- chapter.sgml	4 Dec 2002 15:21:24 -0000	1.122
+++ chapter.sgml	4 Dec 2002 18:25:52 -0000
@@ -74,6 +74,11 @@
 	<para>How to configure and use extended file system access
 	  control lists (ACLs) with UFS.</para>
       </listitem>
+
+      <listitem>
+	<para>How to configure and load access control extension
+	  modules using the TrustedBSD MAC Framework.</para>
+      </listitem>
     </itemizedlist>
 
     <para>Before reading this chapter, you should:</para>
@@ -3531,6 +3536,236 @@
       It is recommended to use the former over the latter to avoid remount
       issues with the root file system.</para>
   </sect1>
+
+  <sect1 id="mac">
+    <sect1info>
+      <authorgroup>
+	<author>
+	  <firstname>Robert</firstname>
+	  <surname>Watson</surname>
+	  <contrib>Sponsored by DARPA and Network Associates Laboratories.
+	    Contributed by </contrib>
+	</author>
+      </authorgroup>
+    </sect1info>
+    <indexterm>
+      <primary>MAC</primary>
+    </indexterm>
+    <title>Mandatory Access Control (MAC)</title>
+
+    <para>FreeBSD 5.0 includes a new kernel security framework, the
+      TrustedBSD MAC Framework.  The MAC Framework permits compile-time,
+      boot-time, and run-time extension of the kernel access control
+      policy, and can be used to load support for Mandatory Access
+      Control (<acronym>MAC</acronym>), and custom security modules
+      such as hardening modules.  The MAC Framework is currently
+      considered to be an experimental feature, and should not yet
+      be used in production environments without careful consideration.
+      It is anticipated that the MAC Framework will be appropriate for
+      more widespread production use by FreeBSD 5.2.</para>
+
+    <para>When configured into a kernel, the MAC Framework permits
+      security modules to augment the existing kernel access control
+      model, restricting access to system services and objects.  For
+      example, the mac_bsdextended module augments file system access
+      control, permitting administrators to provide a firewall-like
+      ruleset constraining access to file system objects based on user
+      ids and group membership.  Some modules require little or no
+      configuration, such as mac_seeotheruids, whereas others perform
+      ubiquitous object labeling, such as mac_biba and mac_mls, and
+      require extensive configuration.</para>
+
+    <para>To enable the MAC Framework in your system kernel, you must
+      add the following entry to your kernel configuration:</para>
+
+    <programlisting>options MAC</programlisting>
+
+    <para>Security policy modules shipped with the base system may
+     be loaded using &man.kldload.8; or in the boot &man.loader.8;
+     They may also be compiled directly into the kernel using the
+     following options, if the use of modules is not desired.</para>
+
+    <para>Different MAC policies may be configured in different ways;
+      frequently, MAC policy modules export configuration parameters
+      using the &man.sysctl.8; <acronym>MIB</acronym> using the
+      security.mac.* namespace.  Policies relying on file system
+      or other labels may require a configuration step that involes
+      assigning initial labels to system objects or creating a
+      policy configuration file.  For information on how to configure
+      and use each policy module, see its man page.</para>
+
+    <para>A variety of tools are available to configure the MAC Framework
+      and labels maintained by various policies.  Extensions have been
+      made to the login and credential management mechanisms
+      (&man.setusercontext.3;) to support initial user labeling using
+      &man.login.conf.5;.  In addition, modifications have been made
+      to &man.su.1;, &man.ps.1;, &man.ls.1;, and &man.ifconfig.8; to
+      inspect and set labels on processes, files, and interfaces.  In
+      addition, several new tools have been added to manage labels
+      on objects, including &man.getfmac.8;, &man.setfmac.8;, and
+      &man.setfsmac.8; to manage labels on files, and &man.getpmac.8; and
+      &man.setpmac.8;.</para>
+
+    <para>What follows is a list of policy modules shipped with FreeBSD
+      5.0.</para>
+    <sect2 id="mac-policy-biba">
+      <title>Biba Integrity Policy (mac_biba)</title>
+      <indexterm>
+	<primary>Biba Integrity Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_biba.ko</para>
+      <para>Kernel option: MAC_BIBA</para>
+      <para>The Biba Integrity Policy (XXXMANPAGE) provides
+	for hierarchal and non-hierarchal labeling of all system
+	objects with integrity data, and the strict enforcement of
+	an information flow policy to prevent corruption of high
+	integrity subjects and data by low-integrity subjects.
+	Integrity is enforced by preventing high integrity
+	subjects (generally processes) from reading load integrity
+	objects (often files), and preventing low integrity
+	subjects from writing to high integrity objects.
+	This security policy is frequently used in commercial
+	trusted systems to provide strong protection for the
+	Trusted Code Base (<acronym>TCB</acronym>).  Because it
+	provides ubiquitous labeling, the Biba integrity policy
+	must be compiled into the kernel or loaded at boot.</para>
+    </sect2>
+    <sect2 id="mac-policy-ifoff">
+      <title>Interface Silencing Policy (mac_ifoff)</title>
+      <indexterm>
+	<primary>Interface Silencing Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_ifoff.ko</para>
+      <para>Kernel option: MAC_IFOFF</para>
+      <para>The interface silencing policy (XXXMANPAGE)
+	prohibits the use of network interfaces during the boot
+	until explicitly enabled, preventing spurious stack output
+	stack response to incoming packets.  This is appropriate
+	for use in environments where the monitoring of packets
+	is required, but no traffic may be generated.</para>
+    </sect2>
+    <sect2 id="mac-policy-lomac">
+      <title>Low-Watermark Mandatory Access Control (LOMAC)
+	(mac_lomac)</title>
+      <indexterm>
+	<primary>Low-Watermark Mandatory Access Control</primary>
+      </indexterm>
+      <indexterm>
+	<primary>LOMAC</primary>
+      </indexterm>
+      <para>Vendor: Network Associates Laboratories</para>
+      <para>Module name: mac_lomac.ko</para>
+      <para>Kernel option: MAC_LOMAC</para>
+      <para>Similar to the Biba Integrity Policy, the LOMAC
+	policy (XXXMANPAGE) relies on the ubiquitous
+	labeling of all system objects with integrity labels.
+	Unlike Biba, LOMAC permits high integrity subjects to
+	read from low integrity objects, but then downgrades the
+	label on the subject to prevent future writes to high
+	integrity objects.  This policy may provide for greater
+	compatibility, as well as require less initial
+	configuration than Biba.  However, as with Biba, it
+	ubiquitously labels objects and must therefore be
+	compiled into the kernel or loaded at boot.</para>
+    </sect2>
+    <sect2 id="mac-policy-mls">
+      <title>Multi-Level Security Policy (MLS) (mac_mls)</title>
+      <indexterm>
+	<primary>Multi-Level Security Policy</primary>
+      </indexterm>
+      <indexterm>
+	<primary>MLS</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_mls.ko</para>
+      <para>Kernel option: MAC_MLS</para>
+      <para>Multi-Level Security (<acronym>MLS</acronym>)
+	(XXXMANPAGE) provides for hierarchal and
+	non-hierarchal labeling of all system objects with
+	sensitivity data, and the strict enforcement of an
+	information flow policy to prevent the leakage of
+	confidential data to untrusted parties.  The logical
+	conjugate of the Biba Integrity Policy,
+	<acronym>MLS</acronym> is frequently shipped in
+	commercial trusted operating systems to protect data
+	secrecy in multi-user environments.  Hierarchal labels
+	provide support for the notion of clearances and
+	classifications in traditional parlance; non-hierarchal
+	labels provide support for "need-to-know".  As with
+	Biba, ubiquitous labeling of objects occurs, and it
+	must therefore be compiled into the kernel or loaded
+	at boot.  As with Biba, extensive initial configuration
+	may be required.</para>
+    </sect2>
+    <sect2 id="mac-policy-none">
+      <title>MAC Stub Policy (mac_none)</title>
+      <indexterm>
+	<primary>MAC Stub Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_none.ko</para>
+      <para>Kernel option: MAC_NONE</para>
+      <para>The None policy (XXXMANPAGE) provides a stub
+	sample policy for developers, implementing all entry
+	points, but not changing the system access control
+	policy.  Running this on a production system would
+	not be highly beneficial.</para>
+    </sect2>
+    <sect2 id="mac-policy-partition">
+      <title>Process Partition Policy (mac_partition)</title>
+      <indexterm>
+	<primary>Process Partition Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_partition.ko</para>
+      <para>Kernel option: MAC_PARTITION</para>
+      <para>The Partition policy (XXXMANPAGE) provides for a
+	simple process visibility limitation, assigning labels to
+	processes identifying what numeric system partition they
+	are present in.  If none, all other processes are visible
+	using standard monitoring tools; if a partition identifier
+	is present, then only other processes in the same
+	partition are visible.  This policy may be compiled into
+	the kernel, loaded at boot, or loaded at run-time.</para>
+    </sect2>
+    <sect2 id="mac-policy-seeotheruids">
+      <title>See Other Uids Policy (mac_seeotheruids)</title>
+      <indexterm>
+	<primary>See Other Uids Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_seeotheruids.ko</para>
+      <para>Kernel option: MAC_BIBA</para>
+      <para>The See Other Uids policy (XXXMANPAGE) implements
+	a similar process visibility model to mac_partition,
+	except that it relies on process credentials to control
+	visibility of processes, rather than partition labels.  This
+	policy may be configured to exempt certain users and groups,
+	including permitting system operators to view all processes
+	without special privilege.  This policy may be compiled into
+	the kernel, loaded at boot, or loaded at run-time.</para>
+    </sect2>
+    <sect2 id="mac-policy-test">
+      <title>MAC Framework Test Policy</title>
+      <indexterm>
+	<primary>MAC Framework Test Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_test.ko</para>
+      <para>Kernel option: MAC_TEST</para>
+      <para>The Test policy (XXXMANPAGE) provides a regression test
+	environment for the MAC Framework, and will cause a
+	fail-stop in the event that internal MAC Framework assertions
+	about proper data labeling fail.  This module can be used to
+	detect failures to properly label system objects in the kernel
+	implementation.  This policy may be compiled into the kernel,
+	loaded at boot, or loaded at run-time.</para>
+    </sect2>
+
+  </sect1>
+ 
 </chapter>
 
 <!--
