- Merge the following from the English version:

r15170 -> r15267	head/ja_JP.eucJP/books/handbook/security/chapter.xml
This commit is contained in:
Ryusuke SUZUKI 2013-11-07 11:44:29 +00:00
parent 7587c96f94
commit c057dbfa2b
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43115

View file

@ -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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
<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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
<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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
</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>