- Merge the following from the English version:
r15155 -> r15170 head/ja_JP.eucJP/books/handbook/security/chapter.xml MAC section is not translated and commented out. This section will be removed from this chapter.
This commit is contained in:
Ryusuke SUZUKI
parent
1585d9ebb7
commit
7587c96f94
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43114
1 changed files with 237 additions and 1 deletions
|
|
@ -3,7 +3,7 @@
|
|||
The FreeBSD Documentation Project
|
||||
The FreeBSD Japanese Documentation Project
|
||||
|
||||
Original revision: 1.122
|
||||
Original revision: r15170
|
||||
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
|
||||
|
|
@ -86,6 +86,12 @@
|
|||
<para>拡張されたファイルシステムアクセス制御リスト
|
||||
(ACL) の UFS での設定および使用方法</para>
|
||||
</listitem>
|
||||
<!--
|
||||
<listitem>
|
||||
<para>How to configure and load access control extension
|
||||
modules using the TrustedBSD MAC Framework.</para>
|
||||
</listitem>
|
||||
-->
|
||||
</itemizedlist>
|
||||
|
||||
<para>この章を読む前に、次のことが必要になります。</para>
|
||||
|
|
@ -3865,4 +3871,234 @@ user@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
|
|||
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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue