PERFORCE change 26450 for review
Chris Costello
chris at freebsd.org
Thu Mar 6 22:25:21 GMT 2003
http://perforce.freebsd.org/chv.cgi?CH=26450
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">
<sect1info>
<authorgroup>
- <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>
</authorgroup>
- <!-- 18 Nov 2002 -->
</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>
- <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 &man.mac.mls.4;, 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 &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>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>)
+ (&man.mac.mls.4;) 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>
- <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>
</sect1>
-<<<<
</chapter>
<!--
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list