PERFORCE change 26450 for review

Chris Costello chris at
Thu Mar 6 22:25:21 GMT 2003

Change 26450 by chris at chris_holly on 2003/03/06 14:24:56

	Bring the vendor version of chapter.sgml back up to the (incorrectly)
	spammed head of this branch.

Affected files ...

.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#13 integrate

Differences ...

==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#13 (text+ko) ====

@@ -3546,58 +3546,261 @@
   <sect1 id="mac">
-        <author>
-          <firstname>Chris</firstname>
-          <surname>Costello</surname>
-          <contrib>Contributed by </contrib>
-        </author>
+	<author>
+	  <firstname>Robert</firstname>
+	  <surname>Watson</surname>
+	  <contrib>Sponsored by DARPA and Network Associates Laboratories.
+	    Contributed by </contrib>
+	</author>
-      <!-- 18 Nov 2002 -->
+    <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>
-    <title>Mandatory Access Control</title>
+    <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 &man.mac.bsdextended.4; 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 &man.mac.seeotheruids.4,
+      whereas others perform ubiquitous object labeling, such as
+      &man.mac.biba.4; and &;, and require extensive
+      configuration.</para>
-    <para>Mandatory Access Control, or MAC, permits administrators to
-      enforce non-bypassable security policies for all subjects (such
-      as processes, sockets, pipes) and objects (such as file system
-      objects, processes, sockets, pipes).  A framework is provided in
-      order to load, unload and standardize individual MAC policy
-      modules.</para>
+    <para>To enable the MAC Framework in your system kernel, you must
+      add the following entry to your kernel configuration:</para>
-    <para>The MAC framework and policies were contributed by the
-      TrustedBSD Project.</para>
+    <programlisting>options MAC</programlisting>
-    <note><para>This feature is in FreeBSD versions 5.0 and
-        later.</para></note>
+    <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>
-    <sect2 id="mac-basics">
-      <title>A Basic Look at MAC</title>
+    <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
+      <varname>security.mac</varname> 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>The main benefits of MAC lie in its modular structure.
-        A variety of policies are available, all of which are
-        available as loadable kernel modules.  A MAC policy is
-        generally defined as the code which determines access
-        controls, often based on labels applied to subjects (e.g.
-        processes) and objects (e.g. files, processes, sockets,
-        network interfaces).</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 &;, &;, &;, 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>Each subject and each object in a system where MAC is
-        enabled has a policy label associated with it.  Typically
-        there is information in a label for each policy currently
-        enforced in the system.  See &man.maclabel.7; for more info.</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: <literal>MAC_BIBA</literal></para>
+      <indexterm>
+	<primary>TCB</primary>
+      </indexterm>
+      <para>The Biba Integrity Policy (&man.mac.biba.4;) provides
+	for hierarchical and non-hierarchical 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 low 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-bsdextended">
+      <title>File System Firewall Policy (mac_bsdextended)</title>
+      <indexterm>
+	<primary>File System Firewall Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_bsdextended.ko</para>
+      <para>Kernel option: <literal>MAC_BSDEXTENDED</literal></para>
+      <para> The File System Firewall Policy (&man.mac.bsdextended.4;)
+	provides an extension to the BSD file system permission model,
+	permitting the administrator to define a set of firewall-like
+	rules for limiting access to file system objects owned by
+	other users and groups.  Managed using &man.ugidfw.8;, rules
+	may limit access to files and directories based on the uid
+	and gids of the process attempting the access, and the owner
+	and group of the target of the access attempt.  All rules
+	are restrictive, so they may be placed in any order.  This policy
+	requires no prior configuration or labeling, and may be
+	appropriate in multi-user environments where mandatory limits
+	on inter-user data exchange are required.  Caution should be
+	exercised in limiting access to files owned by the super-user or
+	other system user ids, as many useful programs and directories
+	are owned by these users.  As with a network firewall,
+	improper application of file system firewall rules may render
+	the system unusable.  New tools to manage the rule set may be
+	easily written using the &man.libugidfw.3; library.</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: <literal>MAC_IFOFF</literal></para>
+      <para>The interface silencing policy (&man.mac.ifoff.4;)
+	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: <literal>MAC_LOMAC</literal></para>
+      <para>Similar to the Biba Integrity Policy, the LOMAC
+	policy (&man.mac.lomac.4;) 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: <literal>MAC_MLS</literal></para>
+      <para>Multi-Level Security (<acronym>MLS</acronym>)
+        (&;) provides for hierarchical and non-hierarchical
+        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-hierarchical labels provide support
+        for <quote>need-to-know.</quote>  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: <literal>MAC_NONE</literal></para>
+      <para>The None policy (&man.mac.none.4;) 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: <literal>MAC_PARTITION</literal></para>
+      <para>The Partition policy (&man.mac.partition.4;) 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: <literal>MAC_SEEOTHERUIDS</literal></para>
+      <para>The See Other Uids policy (&man.mac.seeotheruids.4;)
+        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 (mac_test)</title>
+      <indexterm>
+	<primary>MAC Framework Test Policy</primary>
+      </indexterm>
+      <para>Vendor: TrustedBSD Project</para>
+      <para>Module name: mac_test.ko</para>
+      <para>Kernel option: <literal>MAC_TEST</literal></para>
+      <para>The Test policy (&man.mac.test.4;) 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 id="mac-using">
-      <title>Using MAC</title>
-      <sect3 id="mac-using-configure">
-        <title>Configuring a File System for MAC</title>
-        <para>In order to configure a UFS1 file system to have</para>
-      </sect3>
-    </sect2>
To Unsubscribe: send mail to majordomo at
with "unsubscribe trustedbsd-cvs" in the body of the message

More information about the trustedbsd-cvs mailing list