PERFORCE change 26458 for review
Chris Costello
chris at freebsd.org
Fri Mar 7 01:45:28 GMT 2003
http://perforce.freebsd.org/chv.cgi?CH=26458
Change 26458 by chris at chris_holly on 2003/03/06 17:45:07
Replace the MAC section with a section based on my mac(4) man page.
Affected files ...
.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 edit
Differences ...
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 (text+ko) ====
@@ -3548,258 +3548,561 @@
<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>
+ <sect2 id="mac-copyright">
+ <title>Legal Notice</title>
+
+ <para>This documentation was developed for the FreeBSD Project
+ by Chris Costello at Safeport Network Services and Network
+ Associates Laboratories, the Security Research Division of
+ Network Associates, Inc. under DARPA/SPAWAR contract
+ N66001-01-C-8035 (<quote>CBOSS</quote>), as part of the DARPA
+ CHATS research program.</para>
+
+ <para>Redistribution and use in source (SGML DocBook) and
+ 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so
+ forth) with or without modification, are permitted provided
+ that the following conditions are met:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>Redistributions of source code (SGML DocBook) must
+ retain the above copyright notice, this list of conditions
+ and the following disclaimer as the first lines of this
+ file unmodified.</para>
+ </listitem>
+
+ <listitem>
+ <para>Redistributions in compiled form (transformed to other
+ DTDs, converted to PDF, PostScript, RTF and other formats)
+ must reproduce the above copyright notice, this list of
+ conditions and the following disclaimer in the
+ documentation and/or other materials provided with the
+ distribution.</para>
+ </listitem>
+ </orderedlist>
- <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>
+ <important>
+ <para>THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS
+ ASSOCIATES TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
+ NETWORKS ASSOCIATES TECHNOLOGY, INC BE LIABLE FOR ANY
+ DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION,
+ EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.</para>
+ </important>
+ </sect2>
- <para>To enable the MAC Framework in your system kernel, you must
- add the following entry to your kernel configuration:</para>
+ <sect2 id="mac-introduction">
+ <title>Introduction</title>
- <programlisting>options MAC</programlisting>
+ <para>The Mandatory Access Control, or MAC, framework allows
+ administrators to finely control system security by providing
+ for a loadable security policy architecture. It is important
+ to note that due to its nature, MAC security policies may only
+ restrict access relative to one another and the base system
+ policy; they cannot override traditional UNIX security
+ provisions such as file permissions and superuser
+ checks.</para>
- <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>Each system subject (processes, sockets, etc.) and each
+ system object (file system objects, sockets, etc.) can carry
+ with it a MAC label. MAC labels contain data in an arbitrary
+ format taken into consideration in making access control
+ decisions for a given operation. Most MAC labels on system
+ subjects and objects can be modified directly or indirectly by
+ the system administrator. The format for a given policy's
+ label may vary depending on the type of object or subject
+ being labeled. More information on the format for MAC labels
+ can be found in the &man.maclabel.7; man page.</para>
+ </sect2>
+
+ <sect2 id="mac-support">
+ <title>File System Support</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>By default, file system enforcement of labeled MAC
+ policies relies on a single file system label in order to make
+ access control decisions for all the files in a particular
+ file system. With some policies, this configuration may not
+ allow administrators to take full advantage of features. In
+ order to enable support for labeling files on an individual
+ basis for a particular file system, the
+ <quote>multilabel</quote> flag must be enabled on the file
+ system. To set the <quote>multilabel</quote> flag, drop to
+ single-user mode and unmount the file system, then execute the
+ following command:</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>
+ <screen>&prompt.root; <userinput>tunefs -l enable <replaceable>filesystem</replaceable></userinput></screen>
- <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>
+ <para>where <replaceable>filesystem</replaceable> is either the
+ mount point (in &man.fstab.5;) or the special file (in
+ <filename>/dev</filename>) corresponding to the file system on
+ which to enable multilabel suport.</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 id="mac-enforcement">
+ <title>Policy Enforcement</title>
+
+ <para>MAC can be configured to enforce only specific portions of
+ policies (see <xref linkend="mac-configuration">). Policy
+ enforcement is divided into the following areas of the
+ system:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term>File System</term>
+
+ <listitem>
+ <para>File system mounts, modifying directories, modifying
+ files, etc.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>KLD</term>
+
+ <listitem>
+ <para>Loading, unloading, and retrieving statistics on
+ loaded kernel modules</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Network</term>
+
+ <listitem>
+ <para>Network interfaces, &man.bpf.4;, packet delivery and
+ transmission, interface configuration (&man.ioctl.2;,
+ &man.ifconfig.8;)
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Pipes</term>
+
+ <listitem>
+ <para>Creation of and operation on &man.pipe.2;
+ objects</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Processes</term>
+
+ <listitem>
+ <para>Debugging (e.g. &man.ktrace.2;), process visibility
+ (&man.ps.1;), process execution (&man.execve.2;),
+ signalling (&man.kill.2;)</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Sockets</term>
+
+ <listitem>
+ <para>Creation of and operation on &man.socket.2;
+ objects</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>System</term>
+
+ <listitem>
+ <para>Kernel environment (&man.kenv.1;), system accounting
+ (&man.acct.2;), &man.reboot.2;, &man.settimeofday.2;,
+ &man.swapon.2;, &man.sysctl.3;, &man.nfsd.8;-related
+ operations</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>VM</term>
+
+ <listitem>
+ <para>&man.mmap.2;-ed files</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</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 id="mac-setlabel">
+ <title>Setting MAC Labels</title>
+
+ <para>From the command line, each type of system object has its
+ own means for setting and modifying its MAC policy
+ label.</para>
+
+ <informaltable>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Subject/Object</entry>
+ <entry>Utility</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>File system object</entry>
+ <entry>&man.setfmac.8;, &man.setfsmac.8;</entry>
+ </row>
+
+ <row>
+ <entry>Network interface</entry>
+ <entry>&man.ifconfig.8;</entry>
+ </row>
+
+ <row>
+ <entry>TTY (by login class)</entry>
+ <entry>&man.login.conf.5;</entry>
+ </row>
+
+ <row>
+ <entry>User (by login class)</entry>
+ <entry>&man.login.conf.5;</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ <para>Additionally, the &man.su.1; and &man.setpmac.8; utilities
+ can be used to run a command with a different process label
+ than the shell's current label.</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 id="mac-programming">
+ <title>Programming with MAC</title>
+
+ <para>MAC security enforcement itself is transparent to
+ application programs, with the exception that some programs
+ may need to be aware of additional &man.errno.2; returns from
+ various system calls.</para>
+
+ <para>The interface for retrieving, handling, and setting policy
+ labels is documented in the &man.mac.3; man page.</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 id="mac-configuration">
+ <title>Runtime Configuration</title>
+
+ <para>The following &man.sysctl.8; MIBs are available for
+ fine-tuning the enforcement of MAC policies. Unless
+ specifically noted, all MIBs default to <literal>1</literal>
+ (that is, all areas are enforced by default):</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><varname>security.mac.enforce_fs</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies for file system accesses</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_kld</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies on &man.kld.4;</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_network</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies on network interfaces</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_pipe</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies on pipes</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_process</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies between system processes
+ (e.g. &man.ps.1;, &man.ktrace.2;)</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_socket</varname></term>
+
+ <listitem>
+ <para>Enforce MAC policies on sockets</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>security.mac.enforce_system</varname></term>
+
+ <listitem>
+ <para>Enfroce MAC policies on system-related items
+ (e.g. &man.kenv.1;, &man.acct.2;, &man.reboot.2;)</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</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 id="mac-policies">
+ <title>Supported Security Policies</title>
+
+
+ <para>What follows is a list of policy modules shipped with FreeBSD
+ 5.0.</para>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
+
+ <sect3 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>
+ </sect3>
</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>
-
</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