Date: Thu, 6 Mar 2003 17:45:28 -0800 (PST) From: Chris Costello <chris@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 26458 for review Message-ID: <200303070145.h271jSVS086998@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=26458 Change 26458 by chris@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@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303070145.h271jSVS086998>