aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/handbook/mac/chapter.xml
diff options
context:
space:
mode:
authorGabor Kovesdan <gabor@FreeBSD.org>2012-10-01 09:53:01 +0000
committerGabor Kovesdan <gabor@FreeBSD.org>2012-10-01 09:53:01 +0000
commitb4346b9b2dfe86a97907573086dff096850dcb1d (patch)
tree9b951977cbd22dada9b868ac83b1d56791ea3859 /en_US.ISO8859-1/books/handbook/mac/chapter.xml
parentbee5d224febbeba11356aa848006a4f5f9e24b30 (diff)
downloaddoc-b4346b9b2dfe86a97907573086dff096850dcb1d.tar.gz
doc-b4346b9b2dfe86a97907573086dff096850dcb1d.zip
- Rename .sgml files to .xml
- Reflect the rename in referencing files Approved by: doceng (implicit)
Notes
Notes: svn path=/head/; revision=39631
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/mac/chapter.xml')
-rw-r--r--en_US.ISO8859-1/books/handbook/mac/chapter.xml2075
1 files changed, 2075 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
new file mode 100644
index 0000000000..f94e9d5aa1
--- /dev/null
+++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
@@ -0,0 +1,2075 @@
+<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
+<!--
+ The FreeBSD Documentation Project
+ $FreeBSD$
+-->
+
+<chapter id="mac">
+ <chapterinfo>
+ <authorgroup>
+ <author>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ <contrib>Written by </contrib>
+ </author>
+ </authorgroup>
+ </chapterinfo>
+
+ <title>Mandatory Access Control</title>
+
+ <sect1 id="mac-synopsis">
+ <title>Synopsis</title>
+
+ <indexterm><primary>MAC</primary></indexterm>
+ <indexterm>
+ <primary>Mandatory Access Control</primary>
+ <see>MAC</see>
+ </indexterm>
+
+ <para>&os;&nbsp;5.X introduced new security extensions from the
+ TrustedBSD project based on the &posix;.1e draft. Two of the most
+ significant new security mechanisms are file system Access Control
+ Lists (<acronym>ACL</acronym>s) and Mandatory Access Control
+ (<acronym>MAC</acronym>) facilities. Mandatory Access Control allows
+ new access control modules to be loaded, implementing new security
+ policies. Some provide protections of a narrow subset of the
+ system, hardening a particular service. Others provide
+ comprehensive labeled security across all subjects and objects.
+ The mandatory part
+ of the definition comes from the fact that the enforcement of
+ the controls is done by administrators and the system, and is
+ not left up to the discretion of users as is done with
+ discretionary access control (<acronym>DAC</acronym>, the standard
+ file and System V <acronym>IPC</acronym> permissions on &os;).</para>
+
+ <para>This chapter will focus on the
+ Mandatory Access Control Framework (<acronym>MAC</acronym> Framework), and a set
+ of pluggable security policy modules enabling various security
+ mechanisms.</para>
+
+ <para>After reading this chapter, you will know:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>What <acronym>MAC</acronym> security policy modules are currently
+ included in &os; and their associated mechanisms.</para>
+ </listitem>
+
+ <listitem>
+ <para>What <acronym>MAC</acronym> security policy modules implement as
+ well as the difference between a labeled and non-labeled
+ policy.</para>
+ </listitem>
+
+ <listitem>
+ <para>How to efficiently configure a system to use
+ the <acronym>MAC</acronym> framework.</para>
+ </listitem>
+
+ <listitem>
+ <para>How to configure the different security policy modules included with the
+ <acronym>MAC</acronym> framework.</para>
+ </listitem>
+
+ <listitem>
+ <para>How to implement a more secure environment using the
+ <acronym>MAC</acronym> framework and the examples
+ shown.</para>
+ </listitem>
+
+ <listitem>
+ <para>How to test the <acronym>MAC</acronym> configuration
+ to ensure the framework has been properly implemented.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Before reading this chapter, you should:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Understand &unix; and &os; basics
+ (<xref linkend="basics"/>).</para>
+ </listitem>
+
+ <listitem>
+ <para>Be familiar with
+ the basics of kernel configuration/compilation
+ (<xref linkend="kernelconfig"/>).</para>
+ </listitem>
+
+ <listitem>
+ <para>Have some familiarity with security and how it
+ pertains to &os; (<xref linkend="security"/>).</para>
+ </listitem>
+ </itemizedlist>
+
+ <warning>
+ <para>The improper use of the
+ information contained herein may cause loss of system access,
+ aggravation of users, or inability to access the features
+ provided by X11. More importantly, <acronym>MAC</acronym> should not
+ be relied upon to completely secure a system. The
+ <acronym>MAC</acronym> framework only augments
+ existing security policy; without sound security practices and
+ regular security checks, the system will never be completely
+ secure.</para>
+
+ <para>It should also be noted that the examples contained
+ within this chapter are just that, examples. It is not
+ recommended that these particular settings be rolled out
+ on a production system. Implementing the various security policy modules takes
+ a good deal of thought and testing. One who does not fully understand
+ exactly how everything works may find him or herself going
+ back through the entire system and reconfiguring many files
+ or directories.</para>
+ </warning>
+
+ <sect2>
+ <title>What Will Not Be Covered</title>
+
+ <para>This chapter covers a broad range of security issues relating
+ to the <acronym>MAC</acronym> framework. The
+ development of new <acronym>MAC</acronym> security policy modules
+ will not be covered. A number of security policy modules included with the
+ <acronym>MAC</acronym> framework have specific characteristics
+ which are provided for both testing and new module
+ development. These include the &man.mac.test.4;,
+ &man.mac.stub.4; and &man.mac.none.4;.
+ For more information on these security policy modules and the various
+ mechanisms they provide, please review the manual pages.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-inline-glossary">
+ <title>Key Terms in This Chapter</title>
+
+ <para>Before reading this chapter, a few key terms must be
+ explained. This will hopefully clear up any confusion that
+ may occur and avoid the abrupt introduction of new terms
+ and information.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>compartment</emphasis>: A compartment is a
+ set of programs and data to be partitioned or separated,
+ where users are given explicit access to specific components
+ of a system. Also, a compartment represents a grouping,
+ such as a work group, department, project, or topic. Using
+ compartments, it is possible to implement a need-to-know
+ security policy.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>high water mark</emphasis>: A high water mark
+ policy is one which permits the raising of security levels
+ for the purpose of accessing higher level information. In
+ most cases, the original level is restored after the process
+ is complete. Currently, the &os; <acronym>MAC</acronym>
+ framework does not have a policy for this, but the definition
+ is included for completeness.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>integrity</emphasis>: Integrity, as a key
+ concept, is the level of trust which can be placed on data.
+ As the integrity of the data is elevated, so does the ability
+ to trust that data.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>label</emphasis>: A label is a security
+ attribute which can be applied to files, directories, or
+ other items in the system. It could be considered
+ a confidentiality stamp; when a label is placed on
+ a file it describes the security properties for that specific
+ file and will only permit access by files, users, resources,
+ etc. with a similar security setting. The meaning and
+ interpretation of label values depends on the policy configuration: while
+ some policies might treat a label as representing the
+ integrity or secrecy of an object, other policies might use
+ labels to hold rules for access.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>level</emphasis>: The increased or decreased
+ setting of a security attribute. As the level increases,
+ its security is considered to elevate as well.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>low water mark</emphasis>: A low water mark
+ policy is one which permits lowering of the security levels
+ for the purpose of accessing information which is less
+ secure. In most cases, the original security level of the
+ user is restored after the process is complete. The only
+ security policy module in &os; to use this is
+ &man.mac.lomac.4;.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>multilabel</emphasis>: The
+ <option>multilabel</option> property is a file system option
+ which can be set in single user mode using the
+ &man.tunefs.8; utility, during the boot operation
+ using the &man.fstab.5; file, or during the creation of
+ a new file system. This option will permit an administrator
+ to apply different <acronym>MAC</acronym> labels on different
+ objects. This option
+ only applies to security policy modules which support labeling.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>object</emphasis>: An object or system
+ object is an entity through which information flows
+ under the direction of a <emphasis>subject</emphasis>.
+ This includes directories, files, fields, screens, keyboards,
+ memory, magnetic storage, printers or any other data
+ storage/moving device. Basically, an object is a data container or
+ a system resource; access to an <emphasis>object</emphasis>
+ effectively means access to the data.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>policy</emphasis>: A collection of rules
+ which defines how objectives are to be achieved. A
+ <emphasis>policy</emphasis> usually documents how certain
+ items are to be handled. This chapter will
+ consider the term <emphasis>policy</emphasis> in this
+ context as a <emphasis>security policy</emphasis>; i.e.
+ a collection of rules which will control the flow of data
+ and information and define whom will have access to that
+ data and information.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>sensitivity</emphasis>: Usually used when
+ discussing <acronym>MLS</acronym>. A sensitivity level is
+ a term used to describe how important or secret the data
+ should be. As the sensitivity level increases, so does the
+ importance of the secrecy, or confidentiality of the data.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>single label</emphasis>: A single label is
+ when the entire file system uses one label to
+ enforce access control over the flow of data. When a file
+ system has this set, which is any time when the
+ <option>multilabel</option> option is not set, all
+ files will conform to the same label setting.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>subject</emphasis>: a subject is any
+ active entity that causes information to flow between
+ <emphasis>objects</emphasis>; e.g., a user, user process,
+ system process, etc. On &os;, this is almost always a thread
+ acting in a process on behalf of a user.</para>
+ </listitem>
+ </itemizedlist>
+ </sect1>
+
+ <sect1 id="mac-initial">
+ <title>Explanation of MAC</title>
+
+ <para>With all of these new terms in mind, consider how the
+ <acronym>MAC</acronym> framework augments the security of
+ the system as a whole. The various security policy modules provided by
+ the <acronym>MAC</acronym> framework could be used to
+ protect the network and file systems, block users from
+ accessing certain ports and sockets, and more. Perhaps
+ the best use of the policy modules is to blend them together, by loading
+ several security policy modules at a time for a multi-layered
+ security environment. In a multi-layered security environment,
+ multiple policy modules are in effect to keep security in check. This
+ is different to a hardening policy, which typically hardens
+ elements of a system that is used only for specific purposes.
+ The only downside is administrative overhead in cases of
+ multiple file system labels, setting network access control
+ user by user, etc.</para>
+
+ <para>These downsides are minimal when compared to the lasting
+ effect of the framework; for instance, the ability to pick and choose
+ which policies are required for a specific configuration keeps
+ performance overhead down. The reduction of support for unneeded
+ policies can increase the overall performance of the system as well as
+ offer flexibility of choice. A good implementation would
+ consider the overall security requirements and effectively implement
+ the various security policy modules offered by the framework.</para>
+
+ <para>Thus a system utilizing <acronym>MAC</acronym> features
+ should at least guarantee that a user will not be permitted
+ to change security attributes at will; all user utilities,
+ programs and scripts must work within the constraints of
+ the access rules provided by the selected security policy modules; and
+ that total control of the <acronym>MAC</acronym> access
+ rules are in the hands of the system administrator.</para>
+
+ <para>It is the sole duty of the system administrator to
+ carefully select the correct security policy modules. Some environments
+ may need to limit access control over the network; in these
+ cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and even
+ &man.mac.biba.4; policy modules might make good starting points. In other
+ cases, strict confidentiality of file system objects might
+ be required. Policy modules such as &man.mac.bsdextended.4;
+ and &man.mac.mls.4; exist for this purpose.</para>
+
+ <para>Policy decisions could be made based on network
+ configuration. Perhaps only certain users should be permitted
+ access to facilities provided by &man.ssh.1; to access the
+ network or the Internet. The &man.mac.portacl.4; would be
+ the policy module of choice for these situations. But what should be
+ done in the case of file systems? Should all access to certain
+ directories be severed from other groups or specific
+ users? Or should we limit user or utility access to specific
+ files by setting certain objects as classified?</para>
+
+ <para>In the file system case, access to objects might be
+ considered confidential to some users, but not to others.
+ For an example, a large development team might be broken
+ off into smaller groups of individuals. Developers in
+ project A might not be permitted to access objects written
+ by developers in project B. Yet they might need to access
+ objects created by developers in project C; that is quite a
+ situation indeed. Using the different security policy modules provided by
+ the <acronym>MAC</acronym> framework; users could
+ be divided into these groups and then given access to the
+ appropriate areas without fear of information
+ leakage.</para>
+
+ <para>Thus, each security policy module has a unique way of dealing with
+ the overall security of a system. Module selection should be based
+ on a well thought out security policy. In many cases, the
+ overall policy may need to be revised and reimplemented on
+ the system. Understanding the different security policy modules offered by
+ the <acronym>MAC</acronym> framework will help administrators
+ choose the best policies for their situations.</para>
+
+ <para>The default &os; kernel does not include the option for
+ the <acronym>MAC</acronym> framework; thus the following
+ kernel option must be added before trying any of the examples or
+ information in this chapter:</para>
+
+ <programlisting>options MAC</programlisting>
+
+ <para>And the kernel will require a rebuild and a reinstall.</para>
+
+ <caution>
+ <para>While the various manual pages for <acronym>MAC</acronym>
+ policy modules state that they may be built into the kernel,
+ it is possible to lock the system out of
+ the network and more. Implementing <acronym>MAC</acronym>
+ is much like implementing a firewall, care must be taken
+ to prevent being completely locked out of the system. The
+ ability to revert back to a previous configuration should be
+ considered while the implementation of <acronym>MAC</acronym>
+ remotely should be done with extreme caution.</para>
+ </caution>
+ </sect1>
+
+ <sect1 id="mac-understandlabel">
+ <title>Understanding MAC Labels</title>
+
+ <para>A <acronym>MAC</acronym> label is a security attribute
+ which may be applied to subjects and objects throughout
+ the system.</para>
+
+ <para>When setting a label, the user must be able to comprehend
+ what it is, exactly, that is being done. The attributes
+ available on an object depend on the policy module loaded, and that
+ policy modules interpret their attributes in different
+ ways. If improperly configured due to lack of comprehension, or
+ the inability to understand the implications, the result will
+ be the unexpected and perhaps, undesired, behavior of the
+ system.</para>
+
+ <para>The security label on an object is used as a part of a
+ security access control decision by a policy. With some
+ policies, the label by itself contains all information necessary
+ to make a decision; in other models, the labels may be processed
+ as part of a larger rule set, etc.</para>
+
+ <para>For instance, setting the label of <literal>biba/low</literal>
+ on a file will represent a label maintained by the Biba security policy module,
+ with a value of <quote>low</quote>.</para>
+
+ <para>A few policy modules which support the labeling feature in
+ &os; offer three specific predefined labels. These
+ are the low, high, and equal labels. Although they enforce
+ access control in a different manner with each policy module, you
+ can be sure that the low label will be the lowest setting,
+ the equal label will set the subject or object to be disabled
+ or unaffected, and the high label will enforce the highest
+ setting available in the Biba and <acronym>MLS</acronym>
+ policy modules.</para>
+
+ <para>Within single label file system environments, only one label may be
+ used on objects. This will enforce one set of
+ access permissions across the entire system and in many
+ environments may be all that is required. There are a few
+ cases where multiple labels may be set on objects
+ or subjects in the file system. For those cases, the
+ <option>multilabel</option> option may be passed to
+ &man.tunefs.8;.</para>
+
+ <para>In the case of Biba and <acronym>MLS</acronym>, a numeric
+ label may be set to indicate the precise level of hierarchical
+ control. This numeric level is used to partition or sort
+ information into different groups of say, classification only
+ permitting access to that group or a higher group level.</para>
+
+ <para>In most cases the administrator will only be setting up a
+ single label to use throughout the file system.</para>
+
+ <para><emphasis>Hey wait, this is similar to <acronym>DAC</acronym>!
+ I thought <acronym>MAC</acronym> gave control strictly to the
+ administrator.</emphasis> That statement still holds true, to some
+ extent as <username>root</username> is the one in control and who
+ configures the policies so that users are placed in the
+ appropriate categories/access levels. Alas, many policy modules can
+ restrict the <username>root</username> user as well. Basic
+ control over objects will then be released to the group, but
+ <username>root</username> may revoke or modify the settings
+ at any time. This is the hierarchal/clearance model covered
+ by policies such as Biba and <acronym>MLS</acronym>.</para>
+
+ <sect2>
+ <title>Label Configuration</title>
+
+ <para>Virtually all aspects of label policy module configuration
+ will be performed using the base system utilities. These
+ commands provide a simple interface for object or subject
+ configuration or the manipulation and verification of
+ the configuration.</para>
+
+ <para>All configuration may be done by use of the
+ &man.setfmac.8; and &man.setpmac.8; utilities.
+ The <command>setfmac</command> command is used to set
+ <acronym>MAC</acronym> labels on system objects while the
+ <command>setpmac</command> command is used to set the labels
+ on system subjects. Observe:</para>
+
+ <screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
+
+ <para>If no errors occurred with the command above, a prompt
+ will be returned. The only time these commands are not
+ quiescent is when an error occurred; similarly to the
+ &man.chmod.1; and &man.chown.8; commands. In some cases this
+ error may be a <errorname>Permission denied</errorname> and
+ is usually obtained when the label is being set or modified
+ on an object which is restricted.<footnote><para>Other conditions
+ may produce different failures. For instance, the file may not
+ be owned by the user attempting to relabel the object, the
+ object may not exist or may be read only. A mandatory policy
+ will not allow the process to relabel the file, maybe because
+ of a property of the file, a property of the process, or a
+ property of the proposed new label value. For example: a user
+ running at low integrity tries to change the label of a high
+ integrity file. Or perhaps a user running at low integrity
+ tries to change the label of a low integrity file to a high
+ integrity label.</para></footnote> The system administrator
+ may use the following commands to overcome this:</para>
+
+ <screen>&prompt.root; <userinput>setfmac biba/high test</userinput>
+<errorname>Permission denied</errorname>
+&prompt.root; <userinput>setpmac biba/low setfmac biba/high test</userinput>
+&prompt.root; <userinput>getfmac test</userinput>
+test: biba/high</screen>
+
+ <para>As we see above, <command>setpmac</command>
+ can be used to override the policy module's settings by assigning
+ a different label to the invoked process. The
+ <command>getpmac</command> utility is usually used with currently
+ running processes, such as <application>sendmail</application>:
+ although it takes a process ID in place of
+ a command the logic is extremely similar. If users
+ attempt to manipulate a file not in their access, subject to the
+ rules of the loaded policy modules, the
+ <errorname>Operation not permitted</errorname> error
+ will be displayed by the <function>mac_set_link</function>
+ function.</para>
+
+ <sect3>
+ <title>Common Label Types</title>
+
+ <para>For the &man.mac.biba.4;, &man.mac.mls.4; and
+ &man.mac.lomac.4; policy modules, the ability to assign
+ simple labels is provided. These take the form of high,
+ equal and low, what follows is a brief description of
+ what these labels provide:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>The <literal>low</literal> label is considered the
+ lowest label setting an object or subject may have.
+ Setting this on objects or subjects will block their
+ access to objects or subjects marked high.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>equal</literal> label should only be
+ placed on objects considered to be exempt from the
+ policy.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>high</literal> label grants an object or
+ subject the highest possible setting.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>With respect to each policy module, each of those settings
+ will instate a different information flow directive. Reading
+ the proper manual pages will further explain the traits of
+ these generic label configurations.</para>
+
+ <sect4>
+ <title>Advanced Label Configuration</title>
+
+ <para>Numeric grade labels are used for
+ <literal>comparison:compartment+compartment</literal>; thus
+ the following:</para>
+
+ <programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting>
+
+ <para>May be interpreted as:</para>
+
+ <para><quote>Biba Policy Label</quote>/<quote>Grade 10</quote>
+ :<quote>Compartments 2, 3 and 6</quote>:
+ (<quote>grade 5 ...</quote>)</para>
+
+ <para>In this example, the first grade would be considered
+ the <quote>effective grade</quote> with
+ <quote>effective compartments</quote>, the second grade
+ is the low grade and the last one is the high grade.
+ In most configurations these settings will not be used;
+ indeed, they offered for more advanced
+ configurations.</para>
+
+ <para>When applied to system objects, they will only have a
+ current grade/compartments as opposed to system subjects
+ as they reflect the range of available rights in the system,
+ and network interfaces, where they are used for access
+ control.</para>
+
+ <para>The grade and compartments in a subject and object pair
+ are used to construct a relationship referred to as
+ <quote>dominance</quote>, in which a subject dominates an
+ object, the object dominates the subject, neither dominates
+ the other, or both dominate each other. The
+ <quote>both dominate</quote> case occurs when the two labels
+ are equal. Due to the information flow nature of Biba, you
+ have rights to a set of compartments,
+ <quote>need to know</quote>, that might correspond to
+ projects, but objects also have a set of compartments.
+ Users may have to subset their rights using
+ <command>su</command> or <command>setpmac</command> in order
+ to access objects in a compartment from which they are not
+ restricted.</para>
+ </sect4>
+ </sect3>
+
+ <sect3>
+ <title>Users and Label Settings</title>
+
+ <para>Users themselves are required to have labels so that
+ their files and processes may properly interact with the
+ security policy defined on the system. This is
+ configured through the <filename>login.conf</filename> file
+ by use of login classes. Every policy module that uses labels
+ will implement the user class setting.</para>
+
+ <para>An example entry containing every policy module setting is displayed
+ below:</para>
+
+ <programlisting>default:\
+ :copyright=/etc/COPYRIGHT:\
+ :welcome=/etc/motd:\
+ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
+ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\
+ :manpath=/usr/share/man /usr/local/man:\
+ :nologin=/usr/sbin/nologin:\
+ :cputime=1h30m:\
+ :datasize=8M:\
+ :vmemoryuse=100M:\
+ :stacksize=2M:\
+ :memorylocked=4M:\
+ :memoryuse=8M:\
+ :filesize=8M:\
+ :coredumpsize=8M:\
+ :openfiles=24:\
+ :maxproc=32:\
+ :priority=0:\
+ :requirehome:\
+ :passwordtime=91d:\
+ :umask=022:\
+ :ignoretime@:\
+ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:</programlisting>
+
+ <para>The <literal>label</literal> option is used to set the
+ user class default label which will be enforced by
+ <acronym>MAC</acronym>. Users will never be permitted to
+ modify this value, thus it can be considered not optional
+ in the user case. In a real configuration, however, the
+ administrator will never wish to enable every policy module.
+ It is recommended that the rest of this chapter be reviewed
+ before any of this configuration is implemented.</para>
+
+ <note>
+ <para>Users may change their label after the initial login;
+ however, this change is subject constraints of the policy.
+ The example above tells the Biba policy that a process's
+ minimum integrity is 5, its maximum is 15, but the default
+ effective label is 10. The process will run at 10 until
+ it chooses to change label, perhaps due to the user using
+ the setpmac command, which will be constrained by Biba to
+ the range set at login.</para>
+ </note>
+
+ <para>In all cases, after a change to
+ <filename>login.conf</filename>, the login class capability
+ database must be rebuilt using <command>cap_mkdb</command>
+ and this will be reflected throughout every forthcoming
+ example or discussion.</para>
+
+ <para>It is useful to note that many sites may have a
+ particularly large number of users requiring several
+ different user classes. In depth planning is required
+ as this may get extremely difficult to manage.</para>
+ </sect3>
+
+ <sect3>
+ <title>Network Interfaces and Label Settings</title>
+
+ <para>Labels may also be set on network interfaces to help
+ control the flow of data across the network. In all cases
+ they function in the same way the policies function with
+ respect to objects. Users at high settings in
+ <literal>biba</literal>, for example, will not be permitted
+ to access network interfaces with a label of low.</para>
+
+ <para>The <option>maclabel</option> may be passed to
+ <command>ifconfig</command> when setting the
+ <acronym>MAC</acronym> label on network interfaces. For
+ example:</para>
+
+ <screen>&prompt.root; <userinput>ifconfig bge0 maclabel biba/equal</userinput></screen>
+
+ <para>will set the <acronym>MAC</acronym> label of
+ <literal>biba/equal</literal> on the &man.bge.4; interface.
+ When using a setting similar to
+ <literal>biba/high(low-high)</literal> the entire label should
+ be quoted; otherwise an error will be returned.</para>
+
+ <para>Each policy module which supports labeling has a tunable
+ which may be used to disable the <acronym>MAC</acronym>
+ label on network interfaces. Setting the label to
+ <option>equal</option> will have a similar effect. Review
+ the output from <command>sysctl</command>, the policy manual
+ pages, or even the information found later in this chapter
+ for those tunables.</para>
+ </sect3>
+ </sect2>
+
+ <sect2>
+ <title>Singlelabel or Multilabel?</title>
+<!-- Stopped here with my edits -->
+ <para>By default the system will use the
+ <option>singlelabel</option> option. But what does this
+ mean to the administrator? There are several differences
+ which, in their own right, offer pros and cons to the
+ flexibility in the systems security model.</para>
+
+ <para>The <option>singlelabel</option> only permits for one
+ label, for instance <literal>biba/high</literal> to be used
+ for each subject or object. It provides for lower
+ administration overhead but decreases the flexibility of
+ policies which support labeling. Many administrators may
+ want to use the <option>multilabel</option> option in
+ their security policy.</para>
+
+ <para>The <option>multilabel</option> option will permit each
+ subject or object to have its own independent
+ <acronym>MAC</acronym> label in
+ place of the standard <option>singlelabel</option> option
+ which will allow only one label throughout the partition.
+ The <option>multilabel</option> and <option>single</option>
+ label options are only required for the policies which
+ implement the labeling feature, including the Biba, Lomac,
+ <acronym>MLS</acronym> and <acronym>SEBSD</acronym>
+ policies.</para>
+
+ <para>In many cases, the <option>multilabel</option> may not need
+ to be set at all. Consider the following situation and
+ security model:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>&os; web-server using the <acronym>MAC</acronym>
+ framework and a mix of the various policies.</para>
+ </listitem>
+
+ <listitem>
+ <para>This machine only requires one label,
+ <literal>biba/high</literal>, for everything in the system.
+ Here the file system would not require the
+ <option>multilabel</option> option as a single label
+ will always be in effect.</para>
+ </listitem>
+
+ <listitem>
+ <para>But, this machine will be a web server and should have
+ the web server run at <literal>biba/low</literal> to prevent
+ write up capabilities. The Biba policy and how it works
+ will be discussed later, so if the previous comment was
+ difficult to interpret just continue reading and return.
+ The server could use a separate partition set at
+ <literal>biba/low</literal> for most if not all of its
+ runtime state. Much is lacking from this example, for
+ instance the restrictions on data, configuration and user
+ settings; however, this is just a quick example to prove the
+ aforementioned point.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>If any of the non-labeling policies are to be used,
+ then the <option>multilabel</option> option would never
+ be required. These include the <literal>seeotheruids</literal>,
+ <literal>portacl</literal> and <literal>partition</literal>
+ policies.</para>
+
+ <para>It should also be noted that using
+ <option>multilabel</option> with a partition and establishing
+ a security model based on <option>multilabel</option>
+ functionality could open the doors for higher administrative
+ overhead as everything in the file system would have a label.
+ This includes directories, files, and even device
+ nodes.</para>
+
+ <para>The following command will set <option>multilabel</option>
+ on the file systems to have multiple labels. This may only be
+ done in single user mode:</para>
+
+ <screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen>
+
+ <para>This is not a requirement for the swap file
+ system.</para>
+
+ <note>
+ <para>Some users have experienced problems with setting the
+ <option>multilabel</option> flag on the root partition.
+ If this is the case, please review the
+ <xref linkend="mac-troubleshoot"/> of this chapter.</para>
+ </note>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-planning">
+ <title>Planning the Security Configuration</title>
+
+ <para>Whenever a new technology is implemented, a planning phase is
+ always a good idea. During the planning stages, an administrator
+ should in general look at the <quote>big picture</quote>, trying
+ to keep in view at least the following:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>The implementation requirements;</para>
+ </listitem>
+
+ <listitem>
+ <para>The implementation goals;</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>For <acronym>MAC</acronym> installations, these include:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>How to classify information and resources available on
+ the target systems.</para>
+ </listitem>
+
+ <listitem>
+ <para>What sorts of information or resources to restrict
+ access to along with the type of restrictions that should be
+ applied.</para>
+ </listitem>
+
+ <listitem>
+ <para>Which <acronym>MAC</acronym> module or modules will be
+ required to achieve this goal.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>It is always possible to reconfigure and change the
+ system resources and security settings, it is quite often very inconvenient to
+ search through the system and fix existing files and user
+ accounts. Planning helps to ensure a trouble-free and efficient
+ trusted system implementation. A trial run of the trusted system,
+ including the configuration, is often vital and definitely
+ beneficial <emphasis>before</emphasis> a <acronym>MAC</acronym>
+ implementation is used on production systems. The idea of just
+ letting loose on a system
+ with <acronym>MAC</acronym> is like setting up for failure.</para>
+
+ <para>Different environments may have explicit needs and
+ requirements. Establishing an in depth and complete security
+ profile will decrease the need of changes once the system
+ goes live. As such, the future sections will cover the
+ different modules available to administrators; describe their
+ use and configuration; and in some cases provide insight on
+ what situations they would be most suitable for. For instance,
+ a web server might roll out the &man.mac.biba.4; and
+ &man.mac.bsdextended.4; policies. In other cases, a machine
+ with very few local users, the &man.mac.partition.4; might
+ be a good choice.</para>
+ </sect1>
+
+ <sect1 id="mac-modules">
+ <title>Module Configuration</title>
+
+ <para>Every module included with the <acronym>MAC</acronym>
+ framework may be either compiled into the kernel as noted above
+ or loaded as a run-time kernel module.
+ The recommended method is to add the module name to the
+ <filename>/boot/loader.conf</filename> file so that it will load
+ during the initial boot operation.</para>
+
+ <para>The following sections will discuss the various
+ <acronym>MAC</acronym> modules and cover their features.
+ Implementing them into a specific environment will also
+ be a consideration of this chapter. Some modules support
+ the use of labeling, which is controlling access by enforcing
+ a label such as <quote>this is allowed and this is not</quote>.
+ A label configuration file may control how files may be accessed,
+ network communication can be exchanged, and more. The previous
+ section showed how the <option>multilabel</option> flag could
+ be set on file systems to enable per-file or per-partition
+ access control.</para>
+
+ <para>A single label configuration would enforce only one label
+ across the system, that is why the <command>tunefs</command>
+ option is called <option>multilabel</option>.</para>
+ </sect1>
+
+ <sect1 id="mac-seeotheruids">
+ <title>The MAC seeotheruids Module</title>
+
+ <indexterm>
+ <primary>MAC See Other UIDs Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_seeotheruids.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>options MAC_SEEOTHERUIDS</literal></para>
+
+ <para>Boot option:
+ <literal>mac_seeotheruids_load="YES"</literal></para>
+
+ <para>The &man.mac.seeotheruids.4; module mimics and extends
+ the <literal>security.bsd.see_other_uids</literal> and
+ <literal>security.bsd.see_other_gids</literal>
+ <command>sysctl</command> tunables. This option does
+ not require any labels to be set before configuration and
+ can operate transparently with the other modules.</para>
+
+ <para>After loading the module, the following
+ <command>sysctl</command> tunables may be used to control
+ the features:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.seeotheruids.enabled</literal>
+ will enable the module's features and use the default
+ settings. These default settings will deny users the
+ ability to view processes and sockets owned by other
+ users.</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>security.mac.seeotheruids.specificgid_enabled</literal>
+ will allow a certain group to be exempt from this policy.
+ To exempt specific groups from this policy, use the
+ <literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal>
+ <command>sysctl</command> tunable. In the above example,
+ the <replaceable>XXX</replaceable> should be replaced with the
+ numeric group ID to be exempted.</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>security.mac.seeotheruids.primarygroup_enabled</literal>
+ is used to exempt specific primary groups from this policy.
+ When using this tunable, the
+ <literal>security.mac.seeotheruids.specificgid_enabled</literal>
+ may not be set.</para>
+ </listitem>
+ </itemizedlist>
+ </sect1>
+
+ <sect1 id="mac-bsdextended">
+ <title>The MAC bsdextended Module</title>
+
+ <indexterm>
+ <primary>MAC</primary>
+ <secondary>File System Firewall Policy</secondary>
+ </indexterm>
+ <para>Module name: <filename>mac_bsdextended.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>options MAC_BSDEXTENDED</literal></para>
+
+ <para>Boot option:
+ <literal>mac_bsdextended_load="YES"</literal></para>
+
+ <para>The &man.mac.bsdextended.4; module enforces the file system
+ firewall. This module's policy provides an extension to the
+ standard file system permissions model, permitting an
+ administrator to create a firewall-like ruleset to protect files,
+ utilities, and directories in the file system hierarchy. When
+ access to a file system object is attempted, the list of rules
+ is iterated until either a matching rule is located or the end
+ is reached. This behavior may be changed by the use of a
+ &man.sysctl.8; parameter,
+ security.mac.bsdextended.firstmatch_enabled. Similar to
+ other firewall modules in &os;, a file containing access control
+ rules can be created and read by the system at boot time using
+ an &man.rc.conf.5; variable.</para>
+
+ <para>The rule list may be entered using a utility, &man.ugidfw.8;,
+ that has a syntax similar to that of &man.ipfw.8;. More tools
+ can be written by using the functions in the
+ &man.libugidfw.3; library.</para>
+
+ <para>Extreme caution should be taken when working with this
+ module; incorrect use could block access to certain parts of
+ the file system.</para>
+
+ <sect2>
+ <title>Examples</title>
+
+ <para>After the &man.mac.bsdextended.4; module has
+ been loaded, the following command may be used to list the
+ current rule configuration:</para>
+
+ <screen>&prompt.root; <userinput>ugidfw list</userinput>
+0 slots, 0 rules</screen>
+
+ <para>As expected, there are no rules defined. This means that
+ everything is still completely accessible. To create a rule
+ which will block all access by users but leave
+ <username>root</username> unaffected, simply run the
+ following command:</para>
+
+ <screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen>
+
+ <para>This is a very bad idea as it will block all users from
+ issuing even the most simple commands, such as
+ <command>ls</command>. A more patriotic list of rules
+ might be:</para>
+
+ <screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput>
+&prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen>
+
+ <para>This will block any and all access, including directory
+ listings, to <username><replaceable>user2</replaceable></username>'s home
+ directory from the username <username>user1</username>.</para>
+
+ <para>In place of <username>user1</username>, the
+ <option>not uid <replaceable>user2</replaceable></option> could
+ be passed. This will enforce the same access restrictions
+ above for all users in place of just one user.</para>
+
+ <note>
+ <para>The <username>root</username> user will be unaffected
+ by these changes.</para>
+ </note>
+
+ <para>This should provide a general idea of how the
+ &man.mac.bsdextended.4; module may be used to help fortify
+ a file system. For more information, see the
+ &man.mac.bsdextended.4; and the &man.ugidfw.8; manual
+ pages.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-ifoff">
+ <title>The MAC ifoff Module</title>
+
+ <indexterm>
+ <primary>MAC Interface Silencing Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_ifoff.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>options MAC_IFOFF</literal></para>
+
+ <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para>
+
+ <para>The &man.mac.ifoff.4; module exists solely to disable network
+ interfaces on the fly and keep network interfaces from being
+ brought up during the initial system boot. It does not require
+ any labels to be set up on the system, nor does it have a
+ dependency on other <acronym>MAC</acronym> modules.</para>
+
+ <para>Most of the control is done through the
+ <command>sysctl</command> tunables listed below.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.ifoff.lo_enabled</literal> will
+ enable/disable all traffic on the loopback (&man.lo.4;)
+ interface.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.ifoff.bpfrecv_enabled</literal> will
+ enable/disable all traffic on the Berkeley Packet Filter
+ interface (&man.bpf.4;)</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.ifoff.other_enabled</literal> will
+ enable/disable traffic on all other interfaces.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>One of the most common uses of &man.mac.ifoff.4; is network
+ monitoring in an environment where network traffic should not
+ be permitted during the boot sequence. Another suggested use
+ would be to write a script which uses
+ <filename role="package">security/aide</filename> to automatically
+ block network traffic if it finds new or altered files in
+ protected directories.</para>
+ </sect1>
+
+ <sect1 id="mac-portacl">
+ <title>The MAC portacl Module</title>
+
+ <indexterm>
+ <primary>MAC Port Access Control List Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_portacl.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>MAC_PORTACL</literal></para>
+
+ <para>Boot option: <literal>mac_portacl_load="YES"</literal></para>
+
+ <para>The &man.mac.portacl.4; module is used to limit binding to
+ local <acronym>TCP</acronym> and <acronym>UDP</acronym> ports
+ using a variety of <command>sysctl</command> variables. In
+ essence &man.mac.portacl.4; makes it possible to allow
+ non-<username>root</username> users to bind to specified
+ privileged ports, i.e., ports below 1024.</para>
+
+ <para>Once loaded, this module will enable the
+ <acronym>MAC</acronym> policy on all sockets. The following
+ tunables are available:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.portacl.enabled</literal> will
+ enable/disable the policy completely.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.portacl.port_high</literal> will set
+ the highest port number that &man.mac.portacl.4;
+ will enable protection for.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.portacl.suser_exempt</literal> will,
+ when set to a non-zero value, exempt the
+ <username>root</username> user from this policy.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.portacl.rules</literal> will
+ specify the actual mac_portacl policy; see below.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>The actual <literal>mac_portacl</literal> policy, as
+ specified in the <literal>security.mac.portacl.rules</literal>
+ sysctl, is a text string of the form:
+ <literal>rule[,rule,...]</literal> with as many rules as
+ needed. Each rule is of the form:
+ <literal>idtype:id:protocol:port</literal>. The
+ <parameter>idtype</parameter> parameter can be
+ <literal>uid</literal> or <literal>gid</literal> and used to
+ interpret the <parameter>id</parameter> parameter as either a
+ user id or group id, respectively. The
+ <parameter>protocol</parameter> parameter is used to determine if
+ the rule should apply to <acronym>TCP</acronym> or
+ <acronym>UDP</acronym> by setting the parameter to
+ <literal>tcp</literal> or <literal>udp</literal>. The final
+ <parameter>port</parameter> parameter is the port number to allow
+ the specified user or group to bind to.</para>
+
+ <note>
+ <para>Since the ruleset is interpreted directly by the kernel
+ only numeric values can be used for the user ID, group ID, and
+ port parameters. Names cannot be used for users, groups, or
+ services.</para>
+ </note>
+
+ <para>By default, on &unix;-like systems, ports below 1024
+ can only be used by/bound to privileged processes,
+ i.e., those run as <username>root</username>. For
+ &man.mac.portacl.4; to allow non-privileged processes to bind
+ to ports below 1024 this standard &unix; restriction has to be
+ disabled. This can be accomplished by setting the &man.sysctl.8;
+ variables <literal>net.inet.ip.portrange.reservedlow</literal> and
+ <literal>net.inet.ip.portrange.reservedhigh</literal>
+ to zero.</para>
+
+ <para>See the examples below or review the &man.mac.portacl.4;
+ manual page for further information.</para>
+
+ <sect2>
+ <title>Examples</title>
+
+ <para>The following examples should illuminate the above
+ discussion a little better:</para>
+
+ <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
+&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0</userinput></screen>
+
+ <para>First we set &man.mac.portacl.4; to cover the standard
+ privileged ports and disable the normal &unix; bind
+ restrictions.</para>
+
+ <screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen>
+
+ <para>The <username>root</username> user should not be crippled
+ by this policy, thus set the
+ <literal>security.mac.portacl.suser_exempt</literal> to a
+ non-zero value. The &man.mac.portacl.4; module
+ has now been set up to behave the same way &unix;-like systems
+ behave by default.</para>
+
+ <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen>
+
+ <para>Allow the user with <acronym>UID</acronym> 80 (normally
+ the <username>www</username> user) to bind to port 80.
+ This can be used to allow the <username>www</username>
+ user to run a web server without ever having
+ <username>root</username> privilege.</para>
+
+ <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
+
+ <para>Permit the user with the <acronym>UID</acronym> of
+ 1001 to bind to the <acronym>TCP</acronym> ports 110
+ (<quote>pop3</quote>) and 995 (<quote>pop3s</quote>).
+ This will permit this user to start a server that accepts
+ connections on ports 110 and 995.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-partition">
+ <title>The MAC partition Module</title>
+
+ <indexterm>
+ <primary>MAC Process Partition Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_partition.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>options MAC_PARTITION</literal></para>
+
+ <para>Boot option:
+ <literal>mac_partition_load="YES"</literal></para>
+
+ <para>The &man.mac.partition.4; policy will drop processes into
+ specific <quote>partitions</quote> based on their
+ <acronym>MAC</acronym> label. Think of it as a special
+ type of &man.jail.8;, though that is hardly a worthy
+ comparison.</para>
+
+ <para>This is one module that should be added to the
+ &man.loader.conf.5; file so that it loads
+ and enables the policy during the boot process.</para>
+
+ <para>Most configuration for this policy is done using
+ the &man.setpmac.8; utility which will be explained below.
+ The following <command>sysctl</command> tunable is
+ available for this policy:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.partition.enabled</literal> will
+ enable the enforcement of <acronym>MAC</acronym> process
+ partitions.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>When this policy is enabled, users will only be permitted
+ to see their processes, and any others within their partition,
+ but will not be permitted to work with
+ utilities outside the scope of this partition. For instance, a user in the
+ <literal>insecure</literal> class above will not be permitted
+ to access the <command>top</command> command as well as many
+ other commands that must spawn a process.</para>
+
+ <para>To set or drop utilities into a partition label, use the
+ <command>setpmac</command> utility:</para>
+
+ <screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
+
+ <para>This will add the <command>top</command> command to the
+ label set on users in the <literal>insecure</literal> class.
+ Note that all processes spawned by users
+ in the <literal>insecure</literal> class will stay in the
+ <literal>partition/13</literal> label.</para>
+
+ <sect2>
+ <title>Examples</title>
+
+ <para>The following command will show you the partition label
+ and the process list:</para>
+
+ <screen>&prompt.root; <userinput>ps Zax</userinput></screen>
+
+ <para>This next command will allow the viewing of another
+ user's process partition label and that user's currently
+ running processes:</para>
+
+ <screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen>
+
+ <note>
+ <para>Users can see processes in <username>root</username>'s
+ label unless the &man.mac.seeotheruids.4; policy is
+ loaded.</para>
+ </note>
+
+ <para>A really crafty implementation could have all of the
+ services disabled in <filename>/etc/rc.conf</filename> and
+ started by a script that starts them with the proper
+ labeling set.</para>
+
+ <note>
+ <para>The following policies support integer settings
+ in place of the three default labels offered. These options,
+ including their limitations, are further explained in
+ the module manual pages.</para>
+ </note>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-mls">
+ <title>The MAC Multi-Level Security Module</title>
+
+ <indexterm>
+ <primary>MAC Multi-Level Security Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_mls.ko</filename></para>
+
+ <para>Kernel configuration line:
+ <literal>options MAC_MLS</literal></para>
+
+ <para>Boot option: <literal>mac_mls_load="YES"</literal></para>
+
+ <para>The &man.mac.mls.4; policy controls access between subjects
+ and objects in the system by enforcing a strict information
+ flow policy.</para>
+
+ <para>In <acronym>MLS</acronym> environments, a
+ <quote>clearance</quote> level is set in each subject or objects
+ label, along with compartments. Since these clearance or
+ sensibility levels can reach numbers greater than six thousand;
+ it would be a daunting task for any system administrator to
+ thoroughly configure each subject or object. Thankfully, three
+ <quote>instant</quote> labels are already included in this
+ policy.</para>
+
+ <para>These labels are <literal>mls/low</literal>,
+ <literal>mls/equal</literal> and <literal>mls/high</literal>.
+ Since these labels are described in depth in the manual page,
+ they will only get a brief description here:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>The <literal>mls/low</literal> label contains a low
+ configuration which permits it to be dominated by all other
+ objects. Anything labeled with <literal>mls/low</literal>
+ will have a low clearance level and not be permitted to access
+ information of a higher level. In addition, this label will
+ prevent objects of a higher clearance level from writing or
+ passing information on to them.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>mls/equal</literal> label should be
+ placed on objects considered to be exempt from the
+ policy.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>mls/high</literal> label is the highest level
+ of clearance possible. Objects assigned this label will
+ hold dominance over all other objects in the system; however,
+ they will not permit the leaking of information to objects
+ of a lower class.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para><acronym>MLS</acronym> provides for:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>A hierarchical security level with a set of non
+ hierarchical categories;</para>
+ </listitem>
+
+ <listitem>
+ <para>Fixed rules: no read up, no write down (a subject can
+ have read access to objects on its own level or below, but
+ not above. Similarly, a subject can have write access to
+ objects on its own level or above but not beneath.);</para>
+ </listitem>
+
+ <listitem>
+ <para>Secrecy (preventing inappropriate disclosure
+ of data);</para>
+ </listitem>
+
+ <listitem>
+ <para>Basis for the design of systems that concurrently handle
+ data at multiple sensitivity levels (without leaking
+ information between secret and confidential).</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>The following <command>sysctl</command> tunables are
+ available for the configuration of special services and
+ interfaces:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.mls.enabled</literal> is used to
+ enable/disable the <acronym>MLS</acronym> policy.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.mls.ptys_equal</literal> will label
+ all &man.pty.4; devices as <literal>mls/equal</literal> during
+ creation.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.mls.revocation_enabled</literal> is
+ used to revoke access to objects after their label changes
+ to a label of a lower grade.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.mls.max_compartments</literal> is
+ used to set the maximum number of compartment levels with
+ objects; basically the maximum compartment number allowed
+ on a system.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>To manipulate the <acronym>MLS</acronym> labels, the
+ &man.setfmac.8; command has been provided. To assign a label
+ to an object, issue the following command:</para>
+
+ <screen>&prompt.root; <userinput>setfmac mls/5 test</userinput></screen>
+
+ <para>To get the <acronym>MLS</acronym> label for the file
+ <filename>test</filename> issue the following command:</para>
+
+ <screen>&prompt.root; <userinput>getfmac test</userinput></screen>
+
+ <para>This is a summary of the <acronym>MLS</acronym>
+ policy's features. Another approach is to create a master policy
+ file in <filename class="directory">/etc</filename> which
+ specifies the <acronym>MLS</acronym> policy information and to
+ feed that file into the <command>setfmac</command> command. This
+ method will be explained after all policies are covered.</para>
+
+ <sect2>
+ <title>Planning Mandatory Sensitivity</title>
+
+ <para>With the Multi-Level Security Policy Module, an
+ administrator plans for controlling the flow of sensitive
+ information. By default, with its block read up block write
+ down nature, the system defaults everything to a low state.
+ Everything is accessible and an administrator
+ slowly changes this during the configuration stage; augmenting
+ the confidentiality of the information.</para>
+
+ <para>Beyond the three basic label options above, an administrator
+ may group users and groups as required to block the information
+ flow between them. It might be easier to look at the
+ information in clearance levels familiarized with words, for
+ instance classifications such as
+ <literal>Confidential</literal>, <literal>Secret</literal>,
+ and <literal>Top Secret</literal>. Some administrators might
+ just create different groups based on project levels.
+ Regardless of classification method, a well thought out plan
+ must exist before implementing such a restrictive policy.</para>
+
+ <para>Some example situations for this security policy module
+ could be an e-commerce web server, a file server holding critical
+ company information, and financial institution environments.
+ The most unlikely place would be a personal workstation with
+ only two or three users.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-biba">
+ <title>The MAC Biba Module</title>
+
+ <indexterm>
+ <primary>MAC Biba Integrity Policy</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_biba.ko</filename></para>
+
+ <para>Kernel configuration line: <literal>options MAC_BIBA</literal></para>
+
+ <para>Boot option: <literal>mac_biba_load="YES"</literal></para>
+
+ <para>The &man.mac.biba.4; module loads the <acronym>MAC</acronym>
+ Biba policy. This policy works much like that of the
+ <acronym>MLS</acronym> policy with the exception that the rules
+ for information flow
+ are slightly reversed. This is said to prevent the downward
+ flow of sensitive information whereas the <acronym>MLS</acronym>
+ policy prevents the upward flow of sensitive information; thus,
+ much of this section can apply to both policies.</para>
+
+ <para>In Biba environments, an <quote>integrity</quote> label is
+ set on each subject or object. These labels are made up of
+ hierarchal grades, and non-hierarchal components. As an object's
+ or subject's grade ascends, so does its integrity.</para>
+
+ <para>Supported labels are <literal>biba/low</literal>,
+ <literal>biba/equal</literal>, and <literal>biba/high</literal>;
+ as explained below:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>The <literal>biba/low</literal> label is considered the
+ lowest integrity an object or subject may have. Setting
+ this on objects or subjects will block their write access
+ to objects or subjects marked high. They still have read
+ access though.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>biba/equal</literal> label should only be
+ placed on objects considered to be exempt from the
+ policy.</para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>biba/high</literal> label will permit
+ writing to objects set at a lower label, but not
+ permit reading that object. It is recommended that this
+ label be placed on objects that affect the integrity of
+ the entire system.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Biba provides for:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Hierarchical integrity level with a set of non
+ hierarchical integrity categories;</para>
+ </listitem>
+
+ <listitem>
+ <para>Fixed rules: no write up, no read down (opposite of
+ <acronym>MLS</acronym>). A subject can have write access
+ to objects on its own level or below, but not above. Similarly, a
+ subject can have read access to objects on its own level
+ or above, but not below;</para>
+ </listitem>
+
+ <listitem>
+ <para>Integrity (preventing inappropriate modification of
+ data);</para>
+ </listitem>
+
+ <listitem>
+ <para>Integrity levels (instead of MLS sensitivity
+ levels).</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>The following <command>sysctl</command> tunables can
+ be used to manipulate the Biba policy.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>security.mac.biba.enabled</literal> may be used
+ to enable/disable enforcement of the Biba policy on the
+ target machine.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.biba.ptys_equal</literal> may be
+ used to disable the Biba policy on &man.pty.4;
+ devices.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>security.mac.biba.revocation_enabled</literal>
+ will force the revocation of access to objects if the label
+ is changed to dominate the subject.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>To access the Biba policy setting on system objects, use
+ the <command>setfmac</command> and <command>getfmac</command>
+ commands:</para>
+
+ <screen>&prompt.root; <userinput>setfmac biba/low test</userinput>
+&prompt.root; <userinput>getfmac test</userinput>
+test: biba/low</screen>
+
+ <sect2>
+ <title>Planning Mandatory Integrity</title>
+
+ <para>Integrity, different from sensitivity, guarantees that the
+ information will never be manipulated by untrusted parties.
+ This includes information passed between subjects, objects,
+ and both. It ensures that users will only be able to modify
+ and in some cases even access information they explicitly need
+ to.</para>
+
+ <para>The &man.mac.biba.4; security policy module permits an
+ administrator to address which files and programs a user or
+ users may see and invoke while assuring that the programs and
+ files are free from threats and trusted by the system for that
+ user, or group of users.</para>
+
+ <para>During the initial planning phase, an administrator must be
+ prepared to partition users into grades, levels, and areas.
+ Users will be blocked access not only to data but programs
+ and utilities both before and after they start. The system will
+ default to a high label once this policy module is enabled, and
+ it is up to the administrator to configure the different grades
+ and levels for users. Instead of using clearance levels as
+ described above, a good planning method could include topics.
+ For instance, only allow developers modification access to the source code
+ repository, source code compiler, and other development
+ utilities. While other users would be grouped into other
+ categories such as testers, designers, or just ordinary
+ users and would only be permitted read access.</para>
+
+ <para>With its natural security control, a lower integrity subject
+ is unable to write to a higher integrity subject; a higher
+ integrity subject cannot observe or read a lower integrity
+ object. Setting a label at the lowest possible grade could make
+ it inaccessible to subjects. Some prospective environments for
+ this security policy module would include a constrained web
+ server, development and test machine, and source code
+ repository. A less useful implementation would be a personal
+ workstation, a machine used as a router, or a network
+ firewall.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-lomac">
+ <title>The MAC LOMAC Module</title>
+
+ <indexterm>
+ <primary>MAC LOMAC</primary>
+ </indexterm>
+ <para>Module name: <filename>mac_lomac.ko</filename></para>
+
+ <para>Kernel configuration line: <literal>options MAC_LOMAC</literal></para>
+ <para>Boot option: <literal>mac_lomac_load="YES"</literal></para>
+
+ <para>Unlike the <acronym>MAC</acronym> Biba policy, the
+ &man.mac.lomac.4; policy permits access to lower integrity
+ objects only after decreasing the integrity level to not disrupt
+ any integrity rules.</para>
+
+ <para>The <acronym>MAC</acronym> version of the Low-watermark
+ integrity policy, not to be confused with the older &man.lomac.4;
+ implementation, works almost identically to Biba, but with the
+ exception of using floating labels to support subject
+ demotion via an auxiliary grade compartment. This secondary
+ compartment takes the form of <literal>[auxgrade]</literal>.
+ When assigning a lomac policy with an auxiliary grade, it
+ should look a little bit like: <literal>lomac/10[2]</literal>
+ where the number two (2) is the auxiliary grade.</para>
+
+ <para>The <acronym>MAC</acronym> LOMAC policy relies on the
+ ubiquitous labeling of all system objects with integrity labels,
+ permitting subjects to read from low integrity objects and then
+ downgrading the label on the subject to prevent future writes to
+ high integrity objects. This is the
+ <literal>[auxgrade]</literal> option discussed above, thus the
+ policy may provide for greater compatibility and require less
+ initial configuration than Biba.</para>
+
+ <sect2>
+ <title>Examples</title>
+
+ <para>Like the Biba and <acronym>MLS</acronym> policies;
+ the <command>setfmac</command> and <command>setpmac</command>
+ utilities may be used to place labels on system objects:</para>
+
+ <screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput>
+&prompt.root; <userinput>getfmac /usr/home/trhodes</userinput> lomac/high[low]</screen>
+
+ <para>Notice the auxiliary grade here is <literal>low</literal>,
+ this is a feature provided only by the <acronym>MAC</acronym>
+ LOMAC policy.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-implementing">
+ <title>Nagios in a MAC Jail</title>
+
+ <indexterm>
+ <primary>Nagios in a MAC Jail</primary>
+ </indexterm>
+
+ <para>The following demonstration will implement a secure
+ environment using various <acronym>MAC</acronym> modules
+ with properly configured policies. This is only a test and
+ should not be considered the complete answer to everyone's
+ security woes. Just implementing a policy and ignoring it
+ never works and could be disastrous in a production
+ environment.</para>
+
+ <para>Before beginning this process, the
+ <literal>multilabel</literal> option must be set on each file
+ system as stated at the beginning of this chapter. Not doing
+ so will result in errors. While at it, ensure that the
+ <filename role="package">net-mngt/nagios-plugins</filename>,
+ <filename role="package">net-mngt/nagios</filename>, and
+ <filename role="package">www/apache22</filename> ports are all
+ installed, configured, and working correctly.</para>
+
+ <sect2>
+ <title>Create an insecure User Class</title>
+
+ <para>Begin the procedure by adding the following user class
+ to the <filename>/etc/login.conf</filename> file:</para>
+
+ <programlisting>insecure:\
+:copyright=/etc/COPYRIGHT:\
+:welcome=/etc/motd:\
+:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
+:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+:manpath=/usr/share/man /usr/local/man:\
+:nologin=/usr/sbin/nologin:\
+:cputime=1h30m:\
+:datasize=8M:\
+:vmemoryuse=100M:\
+:stacksize=2M:\
+:memorylocked=4M:\
+:memoryuse=8M:\
+:filesize=8M:\
+:coredumpsize=8M:\
+:openfiles=24:\
+:maxproc=32:\
+:priority=0:\
+:requirehome:\
+:passwordtime=91d:\
+:umask=022:\
+:ignoretime@:\
+:label=biba/10(10-10):</programlisting>
+
+ <para>And adding the following line to the default user
+ class:</para>
+
+ <programlisting>:label=biba/high:</programlisting>
+
+ <para>Once this is completed, the following command must be
+ issued to rebuild the database:</para>
+
+ <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
+ </sect2>
+
+ <sect2>
+ <title>Boot Configuration</title>
+
+ <para>Do not reboot yet, just add the following lines to
+ <filename>/boot/loader.conf</filename> so the required
+ modules will load during system initialization:</para>
+
+ <programlisting>mac_biba_load="YES"
+mac_seeotheruids_load="YES"</programlisting>
+ </sect2>
+
+ <sect2>
+ <title>Configure Users</title>
+
+ <para>Set the <username>root</username> user to the default
+ class using:</para>
+
+ <screen>&prompt.root; <userinput>pw usermod root -L default</userinput></screen>
+
+ <para>All user accounts that are not <username>root</username>
+ or system users will now require a login class. The login
+ class is required otherwise users will be refused access
+ to common commands such as &man.vi.1;.
+ The following <command>sh</command> script should do the
+ trick:</para>
+
+ <screen>&prompt.root; <userinput>for x in `awk -F: '($3 &gt;= 1001) &amp;&amp; ($3 != 65534) { print $1 }' \</userinput>
+ <userinput>/etc/passwd`; do pw usermod $x -L default; done;</userinput></screen>
+
+ <para>Drop the <username>nagios</username> and
+ <username>www</username> users into the insecure class:</para>
+
+ <screen>&prompt.root; <userinput>pw usermod nagios -L insecure</userinput></screen>
+ <screen>&prompt.root; <userinput>pw usermod www -L insecure</userinput></screen>
+ </sect2>
+
+ <sect2>
+ <title>Create the Contexts File</title>
+
+ <para>A contexts file should now be created; the following example
+ file should be placed in
+ <filename>/etc/policy.contexts</filename>.</para>
+
+ <programlisting># This is the default BIBA policy for this system.
+
+# System:
+/var/run biba/equal
+/var/run/* biba/equal
+
+/dev biba/equal
+/dev/* biba/equal
+
+/var biba/equal
+/var/spool biba/equal
+/var/spool/* biba/equal
+
+/var/log biba/equal
+/var/log/* biba/equal
+
+/tmp biba/equal
+/tmp/* biba/equal
+/var/tmp biba/equal
+/var/tmp/* biba/equal
+
+/var/spool/mqueue biba/equal
+/var/spool/clientmqueue biba/equal
+
+# For Nagios:
+/usr/local/etc/nagios
+/usr/local/etc/nagios/* biba/10
+
+/var/spool/nagios biba/10
+/var/spool/nagios/* biba/10
+
+# For apache
+/usr/local/etc/apache biba/10
+/usr/local/etc/apache/* biba/10</programlisting>
+
+ <para>This policy will enforce security by setting restrictions
+ on the flow of information. In this specific configuration,
+ users, <username>root</username> and others, should never be
+ allowed to access <application>Nagios</application>.
+ Configuration files and processes that are a part of
+ <application>Nagios</application> will be completely self
+ contained or jailed.</para>
+
+ <para>This file may now be read into our system by issuing the
+ following command:</para>
+
+ <screen>&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput>
+&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput></screen>
+
+ <note>
+ <para>The above file system layout may be different depending
+ on environment; however, it must be run on every single file
+ system.</para>
+ </note>
+
+ <para>The <filename>/etc/mac.conf</filename> file requires
+ the following modifications in the main section:</para>
+
+ <programlisting>default_labels file ?biba
+default_labels ifnet ?biba
+default_labels process ?biba
+default_labels socket ?biba</programlisting>
+ </sect2>
+
+ <sect2>
+ <title>Enable Networking</title>
+
+ <para>Add the following line to
+ <filename>/boot/loader.conf</filename>:</para>
+
+ <programlisting>security.mac.biba.trust_all_interfaces=1</programlisting>
+
+ <para>And the following to the network card configuration stored
+ in <filename>rc.conf</filename>. If the primary Internet
+ configuration is done via <acronym>DHCP</acronym>, this may
+ need to be configured manually after every system boot:</para>
+
+ <programlisting>maclabel biba/equal</programlisting>
+ </sect2>
+
+ <sect2>
+ <title>Testing the Configuration</title>
+
+ <indexterm>
+ <primary>MAC Configuration Testing</primary>
+ </indexterm>
+
+ <para>Ensure that the web server and
+ <application>Nagios</application> will not be started
+ on system initialization, and reboot. Ensure the
+ <username>root</username> user cannot access any of the files
+ in the <application>Nagios</application> configuration
+ directory. If <username>root</username> can issue an &man.ls.1;
+ command on <filename>/var/spool/nagios</filename>, then something
+ is wrong. Otherwise a <quote>permission denied</quote> error
+ should be returned.</para>
+
+ <para>If all seems well, <application>Nagios</application>,
+ <application>Apache</application>, and
+ <application>Sendmail</application> can now be started in a way
+ fitting of the security policy. The following commands will
+ make this happen:</para>
+
+ <screen>&prompt.root; <userinput>cd /etc/mail &amp;&amp; make stop &amp;&amp; \
+setpmac biba/equal make start &amp;&amp; setpmac biba/10\(10-10\) apachectl start &amp;&amp; \
+setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></screen>
+
+ <para>Double check to ensure that everything is working
+ properly. If not, check the log files or error messages. Use
+ the &man.sysctl.8; utility to disable the &man.mac.biba.4;
+ security policy module enforcement and try starting everything
+ again, like normal.</para>
+
+ <note>
+ <para>The <username>root</username> user can change the security
+ enforcement and edit the configuration files without fear.
+ The following command will permit the degradation of the
+ security policy to a lower grade for a newly spawned
+ shell:</para>
+
+ <screen>&prompt.root; <userinput>setpmac biba/10 csh</userinput></screen>
+
+ <para>To block this from happening, force the user into a range
+ via &man.login.conf.5;. If &man.setpmac.8; attempts to run
+ a command outside of the compartment's range, an error will
+ be returned and the command will not be executed. In this
+ case, setting root to
+ <literal>biba/high(high-high)</literal>.</para>
+ </note>
+ </sect2>
+ </sect1>
+
+ <sect1 id="mac-userlocked">
+ <title>User Lock Down</title>
+
+ <para>This example considers a relatively small, fewer than fifty
+ users, storage system. Users would have login capabilities, and
+ be permitted to not only store data but access resources as
+ well.</para>
+
+ <para>For this scenario, the &man.mac.bsdextended.4; mixed with
+ &man.mac.seeotheruids.4; could co-exist and block access not
+ only to system objects, but to hide user processes as
+ well.</para>
+
+ <para>Begin by adding the following line to
+ <filename>/boot/loader.conf</filename>:</para>
+
+ <programlisting>mac_seeotheruids_load="YES"</programlisting>
+
+ <para>The &man.mac.bsdextended.4; security policy module may be
+ activated through the use of the following rc.conf
+ variable:</para>
+
+ <programlisting>ugidfw_enable="YES"</programlisting>
+
+ <para>Default rules stored in
+ <filename>/etc/rc.bsdextended</filename> will be loaded at system
+ initialization; however, the default entries may need
+ modification. Since this machine is expected only to service
+ users, everything may be left commented out except the last
+ two. These will force the loading of user owned system objects
+ by default.</para>
+
+ <para>Add the required users to this machine and reboot. For
+ testing purposes, try logging in as a different user across two
+ consoles. Run the <command>ps aux</command> command to see if
+ processes of other users are visible. Try to run &man.ls.1; on
+ another users home directory, it should fail.</para>
+
+ <para>Do not try to test with the <username>root</username> user
+ unless the specific <command>sysctl</command>s have been modified
+ to block super user access.</para>
+
+ <note>
+ <para>When a new user is added, their &man.mac.bsdextended.4;
+ rule will not be in the ruleset list. To update the ruleset
+ quickly, simply unload the security policy module and reload
+ it again using the &man.kldunload.8; and &man.kldload.8;
+ utilities.</para>
+ </note>
+ </sect1>
+
+ <sect1 id="mac-troubleshoot">
+ <title>Troubleshooting the MAC Framework</title>
+
+ <indexterm>
+ <primary>MAC Troubleshooting</primary>
+ </indexterm>
+
+ <para>During the development stage, a few users reported problems
+ with normal configuration. Some of these problems
+ are listed below:</para>
+
+ <sect2>
+ <title>The <option>multilabel</option> option cannot be enabled on
+ <filename>/</filename></title>
+
+ <para>The <option>multilabel</option> flag does not stay
+ enabled on my root (<filename>/</filename>) partition!</para>
+
+
+ <para>It seems that one out of every fifty users has this
+ problem, indeed, we had this problem during our initial
+ configuration. Further observation of this so called
+ <quote>bug</quote> has lead me to believe that it is a
+ result of either incorrect documentation or misinterpretation
+ of the documentation. Regardless of why it happened, the
+ following steps may be taken to resolve it:</para>
+
+ <procedure>
+ <step>
+ <para>Edit <filename>/etc/fstab</filename> and set the root
+ partition at <option>ro</option> for read-only.</para>
+ </step>
+
+ <step>
+ <para>Reboot into single user mode.</para>
+ </step>
+
+ <step>
+ <para>Run <command>tunefs</command> <option>-l enable</option>
+ on <filename>/</filename>.</para>
+ </step>
+
+ <step>
+ <para>Reboot the system into normal mode.</para>
+ </step>
+
+ <step>
+ <para>Run <command>mount</command> <option>-urw</option>
+ <filename>/</filename> and change the <option>ro</option>
+ back to <option>rw</option> in <filename>/etc/fstab</filename>
+ and reboot the system again.</para>
+ </step>
+
+ <step>
+ <para>Double-check the output from the
+ <command>mount</command> to ensure that
+ <option>multilabel</option> has been properly set on the
+ root file system.</para>
+ </step>
+ </procedure>
+ </sect2>
+
+ <sect2>
+ <title>X11 Server Will Not Start After <acronym>MAC</acronym></title>
+
+ <para>After establishing a secure environment with
+ <acronym>MAC</acronym>, I am no longer able to start
+ X!</para>
+
+ <para>This could be caused by the <acronym>MAC</acronym>
+ <literal>partition</literal> policy or by a mislabeling in
+ one of the <acronym>MAC</acronym> labeling policies. To
+ debug, try the following:</para>
+
+ <procedure>
+ <step>
+ <para>Check the error message; if the user is in the
+ <literal>insecure</literal> class, the
+ <literal>partition</literal> policy may be the culprit.
+ Try setting the user's class back to the
+ <literal>default</literal> class and rebuild the database
+ with the <command>cap_mkdb</command> command. If this
+ does not alleviate the problem, go to step two.</para>
+ </step>
+
+ <step>
+ <para>Double-check the label policies. Ensure that the
+ policies are set correctly for the user in question, the
+ X11 application, and
+ the <filename class="directory">/dev</filename>
+ entries.</para>
+ </step>
+
+ <step>
+ <para>If neither of these resolve the problem, send the
+ error message and a description of your environment to
+ the TrustedBSD discussion lists located at the
+ <ulink url="http://www.TrustedBSD.org">TrustedBSD</ulink>
+ website or to the &a.questions;
+ mailing list.</para>
+ </step>
+ </procedure>
+ </sect2>
+
+ <sect2>
+ <title>Error: &man..secure.path.3; cannot stat <filename>.login_conf</filename></title>
+
+ <para>When I attempt to switch from the <username>root</username> user
+ to another user in the system, the error message
+ <errorname>_secure_path: unable to state .login_conf</errorname> appears.</para>
+
+ <para>This message is usually shown when the user has a higher
+ label setting then that of the user whom they are attempting to
+ become. For instance a user on the system,
+ <username>joe</username>, has a default label of
+ <option>biba/low</option>. The <username>root</username> user,
+ who has a label of <option>biba/high</option>, cannot view
+ <username>joe</username>'s home directory. This will happen
+ regardless if <username>root</username> has used the
+ <command>su</command> command to become <username>joe</username>,
+ or not. In this scenario, the Biba integrity model will not
+ permit <username>root</username> to view objects set at a lower
+ integrity level.</para>
+ </sect2>
+
+ <sect2>
+ <title>The <username>root</username> username is broken!</title>
+
+ <para>In normal or even single user mode, the
+ <username>root</username> is not recognized. The
+ <command>whoami</command> command returns 0 (zero) and
+ <command>su</command> returns <errorname>who are you?</errorname>.
+ What could be going on?</para>
+
+ <para>This can happen if a labeling policy has been disabled,
+ either by a &man.sysctl.8; or the policy module was unloaded.
+ If the policy is being disabled or has been temporarily
+ disabled, then the login capabilities database needs to be
+ reconfigured with the <option>label</option> option being
+ removed. Double check the <filename>login.conf</filename>
+ file to ensure that all <option>label</option> options have
+ been removed and rebuild the database with the
+ <command>cap_mkdb</command> command.</para>
+
+ <para>This may also happen if a policy restricts access to the
+ <filename>master.passwd</filename> file or database. Usually
+ caused by an administrator altering the file under a label
+ which conflicts with the general policy being used by the
+ system. In these cases, the user information would be read
+ by the system and access would be blocked as the file has
+ inherited the new label. Disable the policy via a
+ &man.sysctl.8; and everything should return to normal.</para>
+ </sect2>
+ </sect1>
+</chapter>