svn commit: r43115 - head/ja_JP.eucJP/books/handbook/security

Ryusuke SUZUKI ryusuke at FreeBSD.org
Thu Nov 7 11:44:29 UTC 2013


Author: ryusuke
Date: Thu Nov  7 11:44:29 2013
New Revision: 43115
URL: http://svnweb.freebsd.org/changeset/doc/43115

Log:
  - Merge the following from the English version:
  
  	r15170 -> r15267	head/ja_JP.eucJP/books/handbook/security/chapter.xml

Modified:
  head/ja_JP.eucJP/books/handbook/security/chapter.xml

Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml
==============================================================================
--- head/ja_JP.eucJP/books/handbook/security/chapter.xml	Thu Nov  7 11:31:17 2013	(r43114)
+++ head/ja_JP.eucJP/books/handbook/security/chapter.xml	Thu Nov  7 11:44:29 2013	(r43115)
@@ -3,7 +3,7 @@
      The FreeBSD Documentation Project
      The FreeBSD Japanese Documentation Project
 
-     Original revision: r15170
+     Original revision: r15267
      Waiting for:	1.123 or mac/chapter.xml
 			("mac" referenced from disks).
      Translation note: "fs-acl" section added in rev.1.118 is moved to
@@ -3902,13 +3902,14 @@ user at unfirewalled.myserver.com's passwor
     <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>
+      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 &man.mac.mls.4;, 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>
@@ -3923,11 +3924,11 @@ user at unfirewalled.myserver.com's passwor
     <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>
+      <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>A variety of tools are available to configure the MAC Framework
       and labels maintained by various policies.  Extensions have been
@@ -3950,14 +3951,17 @@ user at unfirewalled.myserver.com's passwor
       </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
+      <para>Kernel option: <literal>MAC_BIBA</literal></para>
+      <indexterm>
+	<primary>TCB</primary>
+      </indexterm>
+      <para>The Biba Integrity Policy (&man.mac.biba.4;) 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
+	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
@@ -3966,6 +3970,33 @@ user at unfirewalled.myserver.com's passwor
 	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>
@@ -3973,8 +4004,8 @@ user at unfirewalled.myserver.com's passwor
       </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)
+      <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
@@ -3992,9 +4023,9 @@ user at unfirewalled.myserver.com's passwor
       </indexterm>
       <para>Vendor: Network Associates Laboratories</para>
       <para>Module name: mac_lomac.ko</para>
-      <para>Kernel option: MAC_LOMAC</para>
+      <para>Kernel option: <literal>MAC_LOMAC</literal></para>
       <para>Similar to the Biba Integrity Policy, the LOMAC
-	policy (XXXMANPAGE) relies on the ubiquitous
+	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
@@ -4015,24 +4046,22 @@ user at unfirewalled.myserver.com's passwor
       </indexterm>
       <para>Vendor: TrustedBSD Project</para>
       <para>Module name: mac_mls.ko</para>
-      <para>Kernel option: MAC_MLS</para>
+      <para>Kernel option: <literal>MAC_MLS</literal></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>
+        (&man.mac.mls.4;) 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 <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>
@@ -4041,8 +4070,8 @@ user at unfirewalled.myserver.com's passwor
       </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
+      <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
@@ -4055,8 +4084,8 @@ user at unfirewalled.myserver.com's passwor
       </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
+      <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
@@ -4072,31 +4101,32 @@ user at unfirewalled.myserver.com's passwor
       </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>
+      <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</title>
+      <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: 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>
+      <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>
 
   </sect1>


More information about the svn-doc-all mailing list