e05926f374
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726 Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455, 41457-41469,41472-41477,41479-41513,41515-41521,41523-41577, 41579-41581,41583-42013 Notes: This merge entirely excludes the en_US/books/handbook/ppp-and-slip/ changes. They will need to be looked at a bit more closely. Note to translators: I am very, very sorry. There was no *clean* way to merge this as separate commits. Trust me, I tried. The revision logs for the ISBN branch should provide some insight to what content has changed. I am more than happy to help out here. Sorry :( Approved by: doceng (implicit)
1943 lines
74 KiB
XML
1943 lines
74 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
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; 5.X introduced new security extensions from the
|
|
<ulink url="http://www.trustedbsd.org">TrustedBSD
|
|
Project</ulink> 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. MAC allows new
|
|
access control modules to be loaded, implementing new security
|
|
policies. Some modules provide protections for 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 indicates that enforcement
|
|
of controls is performed by administrators and the operating
|
|
system. This is in contrast to the default security mechanism
|
|
of Discretionary Access Control (<acronym>DAC</acronym> where
|
|
enforcement is left to the discretion of users.</para>
|
|
|
|
<para>This chapter focuses on the <acronym>MAC</acronym> framework
|
|
and the set of pluggable security policy modules &os; provides
|
|
for enabling various security mechanisms.</para>
|
|
|
|
<para>After reading this chapter, you will know:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Which <acronym>MAC</acronym> security policy modules
|
|
are included in &os; and their associated mechanisms.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The capabilities of <acronym>MAC</acronym> security
|
|
policy modules 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.</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>Have some familiarity with security and how it
|
|
pertains to &os; (<xref linkend="security"/>).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<warning>
|
|
<para>Improper <acronym>MAC</acronym> configuration may cause
|
|
loss of system access, aggravation of users, or inability to
|
|
access the features provided by
|
|
<application>Xorg</application>. More importantly,
|
|
<acronym>MAC</acronym> should not be relied upon to completely
|
|
secure a system. The <acronym>MAC</acronym> framework only
|
|
augments an existing security policy. Without sound security
|
|
practices and regular security checks, the system will never
|
|
be completely secure.</para>
|
|
|
|
<para>The examples contained within this chapter are for
|
|
demonstration purposes and the example settings should
|
|
<emphasis>not</emphasis> be implemented on a production
|
|
system. Implementing any security policy takes a good deal of
|
|
understanding, proper design, and thorough testing.</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
|
|
&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, refer to their 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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis>compartment</emphasis>: a set of programs and
|
|
data to be partitioned or separated, where users are given
|
|
explicit access to specific component of a system. A
|
|
compartment represents a grouping, such as a work group,
|
|
department, project, or topic. Compartments make it
|
|
possible to implement a need-to-know-basis security
|
|
policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>high-watermark</emphasis>: this type of
|
|
policy 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 include this type of policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>integrity</emphasis>: 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 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 of that file and will only permit access by
|
|
files, users, and resources with a similar security setting.
|
|
The meaning and interpretation of label values depends on
|
|
the policy configuration. Some policies treat a label as
|
|
representing the integrity or secrecy of an object while
|
|
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-watermark</emphasis>: this type of
|
|
policy permits lowering 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>: this property is a file
|
|
system option which can be set in single user mode using
|
|
&man.tunefs.8;, during boot using &man.fstab.5;, or during
|
|
the creation of a new file system. This option permits
|
|
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 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 or moving device. An
|
|
object is a data container or a system resource. Access to
|
|
an <emphasis>object</emphasis> effectively means access to
|
|
its 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 considers the term
|
|
<emphasis>policy</emphasis> to be a <emphasis>security
|
|
policy</emphasis>, or a collection of rules which controls
|
|
the flow of data and information and defines who has access
|
|
to that data and information.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>sensitivity</emphasis>: usually used when
|
|
discussing Multilevel Security <acronym>MLS</acronym>. A
|
|
sensitivity level describes 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 policy where the
|
|
entire file system uses one label to enforce access control
|
|
over the flow of data. Whenever <option>multilabel</option>
|
|
is not set, all files will conform to the same label
|
|
setting.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>subject</emphasis>: any active entity that
|
|
causes information to flow between
|
|
<emphasis>objects</emphasis> such as a user, user process,
|
|
or system process. 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 or to block users from
|
|
accessing certain ports and sockets. Perhaps the best use of
|
|
the policy modules is to load several security policy modules at
|
|
a time in order to provide a <acronym>MLS</acronym> environment.
|
|
This approach differs from a hardening policy, which typically
|
|
hardens elements of a system which are used only for specific
|
|
purposes. The downside to <acronym>MLS</acronym> is increased
|
|
administrative overhead.</para>
|
|
|
|
<para>The overhead is minimal when compared to the lasting effect
|
|
of a framework which provides the ability to pick and choose
|
|
which policies are required for a specific configuration and
|
|
which 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>A system utilizing <acronym>MAC</acronym> guarantees 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 total control of the
|
|
<acronym>MAC</acronym> access rules are in the hands of the
|
|
system administrator.</para>
|
|
|
|
<para>It is the duty of the system administrator to
|
|
carefully select the correct security policy modules. For an
|
|
environment that needs to limit access control over the network,
|
|
the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4;
|
|
policy modules make good starting points. For an environment
|
|
where strict confidentiality of file system objects is required,
|
|
consider the &man.mac.bsdextended.4; and &man.mac.mls.4; policy
|
|
modules.</para>
|
|
|
|
<para>Policy decisions could be made based on network
|
|
configuration. If only certain users should be permitted
|
|
access to &man.ssh.1;, the &man.mac.portacl.4; policy module is
|
|
a good choice. In the case of file systems, access to objects
|
|
might be considered confidential to some users, but not to
|
|
others. As an example, a large development team might be
|
|
broken off into smaller projects where developers in project A
|
|
might not be permitted to access objects written by developers
|
|
in project B. Yet both projects might need to access objects
|
|
created by developers in project C. 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 objects.</para>
|
|
|
|
<para>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 which may require
|
|
revision and reimplementation. Understanding the different
|
|
security policy modules offered by the <acronym>MAC</acronym>
|
|
framework will help administrators choose the best policies
|
|
for their situations.</para>
|
|
|
|
<caution>
|
|
<para>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 and 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 administrator must be able to
|
|
comprehend what exactly is being done and understand any
|
|
implications in order to prevent unexpected or undesired
|
|
behavior of the system. The attributes available on an object
|
|
depend on the loaded policy module as policy modules interpret
|
|
their attributes in different ways.</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 contains all of the information necessary
|
|
to make a decision. In other policies, the labels may be
|
|
processed as part of a larger rule set. 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: low, high, and
|
|
equal. Such policy modules enforce access control in a
|
|
different manner with each policy module, where the low label is
|
|
the lowest setting, the equal label sets the subject or object
|
|
to be disabled or unaffected, and the high label enforces 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 label enforces 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 by passing <option>multilabel</option> 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 classification only
|
|
permitting access to that group or a higher group level.</para>
|
|
|
|
<para>In most cases, the administrator will set up a single label
|
|
to use throughout the file system. This is similar to
|
|
<acronym>DAC</acronym> 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 hierarchical/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 using &man.setfmac.8; and
|
|
&man.setpmac.8;. <command>setfmac</command> is used to set
|
|
<acronym>MAC</acronym> labels on system objects while
|
|
<command>setpmac</command> is used to set the labels on system
|
|
subjects. Observe:</para>
|
|
|
|
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
|
|
|
|
<para>If the configuration is successful, the prompt will be
|
|
returned without error. A common error is
|
|
<errorname>Permission denied</errorname> which usually occurs
|
|
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 the object 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><command>setpmac</command> can be used to override the
|
|
policy module's settings by assigning a different label to the
|
|
invoked process. <command>getpmac</command> is usually used
|
|
with currently running processes, such as
|
|
<application>sendmail</application>. It takes a process ID in
|
|
place of a command. 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, where:</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 blocks 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 establish a different information flow
|
|
directive. Refer to the manual pages of the module to
|
|
determine 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>.
|
|
For example:</para>
|
|
|
|
<programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting>
|
|
|
|
<para>may be interpreted as <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
|
|
as they are advanced configurations.</para>
|
|
|
|
<para>System objects only have a current grade/compartment.
|
|
System subjects 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 known 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, a user has rights to a set of compartments 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 are required to have labels so that their files
|
|
and processes properly interact with the security policy
|
|
defined on the system. This is configured in
|
|
<filename>login.conf</filename> using 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>To set the
|
|
user class default label which will be enforced by
|
|
<acronym>MAC</acronym>, use <option>label</option>. Users
|
|
are never permitted to modify this value. In a real
|
|
configuration, however, the administrator would never enable
|
|
every policy module. It is recommended that the rest of
|
|
this chapter be reviewed before any configuration is
|
|
implemented.</para>
|
|
|
|
<note>
|
|
<para>Users may change their label after they login, subject
|
|
to the constraints of the policy. The example above tells
|
|
the Biba policy that a process's minimum integrity is 5,
|
|
its maximum is 15, and the default effective label is 10.
|
|
The process will run at 10 until it chooses to change
|
|
label, perhaps due to the user using &man.setpmac.8;,
|
|
which will be constrained by Biba to the configured
|
|
range.</para>
|
|
</note>
|
|
|
|
<para>After any change to
|
|
<filename>login.conf</filename>, the login class capability
|
|
database must be rebuilt using
|
|
<command>cap_mkdb</command>.</para>
|
|
|
|
<para>Many sites have a 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 be set on network interfaces to help
|
|
control the flow of data across the network. Policies
|
|
using network interface labels function in the same way that
|
|
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><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 to prevent an error from being
|
|
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 of <command>sysctl</command>, the policy manual
|
|
pages, and the information in this chapter for more
|
|
information on those tunables.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Singlelabel or Multilabel?</title>
|
|
|
|
<para>By default, the system will use
|
|
<option>singlelabel</option>. For the administrator, there
|
|
are several differences which offer pros and cons to the
|
|
flexibility in the system's security model.</para>
|
|
|
|
<para>A security policy which uses <option>singlelabel</option>
|
|
only permits one label, such as <literal>biba/high</literal>,
|
|
to be used for each subject or object. This provides lower
|
|
administration overhead, but decreases the flexibility of
|
|
policies which support labeling.</para>
|
|
|
|
<para><option>multilabel</option> permits each subject or object
|
|
to have its own independent <acronym>MAC</acronym> label.
|
|
The decision to use <option>multilabel</option> or
|
|
<option>singlelabel</option> is only required for the policies
|
|
which implement the labeling feature, including the Biba,
|
|
Lomac, and <acronym>MLS</acronym> policies.</para>
|
|
|
|
<para>In many cases, <option>multilabel</option> may not be
|
|
needed. 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. This file system would not require
|
|
<option>multilabel</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 server could
|
|
use a separate partition set at
|
|
<literal>biba/low</literal> for most if not all
|
|
of its runtime state.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If any of the non-labeling policies are to be used,
|
|
<option>multilabel</option> would not be required. These
|
|
include the <literal>seeotheruids</literal>,
|
|
<literal>portacl</literal> and <literal>partition</literal>
|
|
policies.</para>
|
|
|
|
<para>Using <option>multilabel</option> with a partition and
|
|
establishing a security model based on
|
|
<option>multilabel</option> functionality could increase
|
|
administrative overhead as everything in the file system has 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 and is not a requirement for the swap
|
|
file system:</para>
|
|
|
|
<screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen>
|
|
|
|
<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 recommended. During the planning stages, an administrator
|
|
should consider the implementation requirements and the
|
|
implementation goals.</para>
|
|
|
|
<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>Which 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>Good planning helps to ensure a trouble-free and efficient
|
|
trusted system implementation. A trial run of the trusted
|
|
system and its configuration should occur
|
|
<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 have different needs and
|
|
requirements. Establishing an in depth and complete security
|
|
profile will decrease the need of changes once the system
|
|
goes live. The rest of this chapter covers the available
|
|
modules, describes their use and configuration, and in some
|
|
cases, provides insight on applicable situations. For instance,
|
|
a web server might use the &man.mac.biba.4; and
|
|
&man.mac.bsdextended.4; policies. In the case of a machine
|
|
with few local users, &man.mac.partition.4; might be a good
|
|
choice.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="mac-modules">
|
|
<title>Module Configuration</title>
|
|
|
|
<para>Beginning with &os; 8.0, the default &os; kernel
|
|
includes <literal>options MAC</literal>. This means that
|
|
every module included with the <acronym>MAC</acronym>
|
|
framework may be loaded as a run-time kernel module. The
|
|
recommended method is to add the module name to
|
|
<filename>/boot/loader.conf</filename> so that it will load
|
|
during boot. Each module also provides a kernel option
|
|
for those administrators who choose to compile their own
|
|
custom kernel.</para>
|
|
|
|
<para>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 enforces 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 See Other UIDs Policy</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 <varname>security.bsd.see_other_uids</varname> and
|
|
<varname>security.bsd.see_other_gids</varname>
|
|
<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><varname>security.mac.seeotheruids.enabled</varname>
|
|
enables the module and uses the default settings which deny
|
|
users the ability to view processes and sockets owned by
|
|
other users.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<varname>security.mac.seeotheruids.specificgid_enabled</varname>
|
|
allows certain groups to be exempt from this policy. To
|
|
exempt specific groups from this policy, use the
|
|
<varname>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></varname>
|
|
<command>sysctl</command> tunable. Replace
|
|
<replaceable>XXX</replaceable> with the numeric group ID to
|
|
be exempted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<varname>security.mac.seeotheruids.primarygroup_enabled</varname>
|
|
is used to exempt specific primary groups from this policy.
|
|
When using this tunable,
|
|
<varname>security.mac.seeotheruids.specificgid_enabled</varname>
|
|
may not be set.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="mac-bsdextended">
|
|
<title>The MAC BSD Extended Policy</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,
|
|
<varname>security.mac.bsdextended.firstmatch_enabled</varname>.
|
|
Similar to other firewall modules in &os;, a file containing
|
|
the 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 &man.ugidfw.8; which has
|
|
a syntax similar to &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 as 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>By default, no rules are defined and everything is
|
|
completely accessible. To create a rule which will block all
|
|
access by users but leave <username>root</username>
|
|
unaffected, 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>. The next example will block
|
|
<username>user1</username> any and all access, including
|
|
directory listings, to
|
|
<username><replaceable>user2</replaceable></username>'s home
|
|
directory:</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>Instead of <username>user1</username>,
|
|
<option>not uid <replaceable>user2</replaceable></option>
|
|
could be used. This enforces the same access restrictions for
|
|
all users instead of just one user.</para>
|
|
|
|
<note>
|
|
<para>The <username>root</username> user is unaffected by
|
|
these changes.</para>
|
|
</note>
|
|
|
|
<para>For more information, refer to &man.mac.bsdextended.4; and
|
|
&man.ugidfw.8;</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="mac-ifoff">
|
|
<title>The MAC Interface Silencing Policy</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 system boot. It does not require any
|
|
labels to be set up on the system, nor does it depend on other
|
|
<acronym>MAC</acronym> modules.</para>
|
|
|
|
<para>Most of this module's control is performed through the
|
|
<command>sysctl</command> tunables listed below.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><varname>security.mac.ifoff.lo_enabled</varname>
|
|
enables or disables all traffic on the loopback (&man.lo.4;)
|
|
interface.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.ifoff.bpfrecv_enabled</varname>
|
|
enables or disables all traffic on the Berkeley Packet
|
|
Filter interface (&man.bpf.4;)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.ifoff.other_enabled</varname>
|
|
enables or disables 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 Port Access Control List Policy</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.
|
|
&man.mac.portacl.4; makes it possible to allow
|
|
non-<username>root</username> users to bind to specified
|
|
privileged ports below 1024.</para>
|
|
|
|
<para>Once loaded, this module enables the
|
|
<acronym>MAC</acronym> policy on all sockets. The following
|
|
tunables are available:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><varname>security.mac.portacl.enabled</varname>
|
|
enables or disables the policy completely.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.portacl.port_high</varname>
|
|
sets the highest port number that &man.mac.portacl.4;
|
|
protects.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.portacl.suser_exempt</varname>,
|
|
when set to a non-zero value, exempts the
|
|
<username>root</username> user from this policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.portacl.rules</varname>
|
|
specifies the mac_portacl policy, which 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 is 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>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<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, ports below 1024 can only be used by or bound
|
|
to privileged processes, which run as
|
|
<username>root</username>. For &man.mac.portacl.4; to allow
|
|
non-privileged processes to bind to ports below 1024, this
|
|
restriction has to be disabled by setting the &man.sysctl.8;
|
|
variables
|
|
<varname>net.inet.ip.portrange.reservedlow</varname> and
|
|
<varname>net.inet.ip.portrange.reservedhigh</varname> to
|
|
zero:</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>See the examples below or refer to &man.mac.portacl.4; for
|
|
further information.</para>
|
|
|
|
<sect2>
|
|
<title>Examples</title>
|
|
|
|
<para>Since the <username>root</username> user should not be
|
|
crippled by this policy, this example starts by setting the
|
|
<varname>security.mac.portacl.suser_exempt</varname> to a
|
|
non-zero value.</para>
|
|
|
|
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen>
|
|
|
|
<para>Next, allow the user with <acronym>UID</acronym> 80
|
|
to bind to port 80. This allows 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:80:tcp:80</userinput></screen>
|
|
|
|
<para>The next example permits 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 permits this user to start a
|
|
server that accepts connections on ports 110 and 995.</para>
|
|
|
|
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="mac-partition">
|
|
<title>The MAC Partition Policy</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. This module should be added to
|
|
&man.loader.conf.5; so that it loads and enables the policy
|
|
at system boot.</para>
|
|
|
|
<para>Most configuration for this policy is done using
|
|
&man.setpmac.8;. One <command>sysctl</command> tunable is
|
|
available for this policy:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><varname>security.mac.partition.enabled</varname>
|
|
enables 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 will not be permitted to
|
|
access <command>top</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 example adds <command>top</command> to the label set on
|
|
users in the <literal>insecure</literal> class. 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 display the partition label
|
|
and the process list:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ps Zax</userinput></screen>
|
|
|
|
<para>This command will display 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 the label of each
|
|
subject or object, along with compartments. Since these
|
|
clearance or sensibility levels can reach numbers greater than
|
|
several 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 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. This label also
|
|
prevents 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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A hierarchical security level with a set of non
|
|
hierarchical categories.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fixed rules of <literal>no read up, no write
|
|
down</literal>. This means that 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, or the prevention of inappropriate disclosure
|
|
of data.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A 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><varname>security.mac.mls.enabled</varname> is used to
|
|
enable or disable the <acronym>MLS</acronym> policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.mls.ptys_equal</varname>
|
|
labels all &man.pty.4; devices as
|
|
<literal>mls/equal</literal> during creation.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.mls.revocation_enabled</varname>
|
|
revokes access to objects after their label changes to a
|
|
label of a lower grade.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.mls.max_compartments</varname>
|
|
sets the maximum number of compartment levels allowed on a
|
|
system.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>To manipulate the <acronym>MLS</acronym> labels, use
|
|
&man.setfmac.8;. 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>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
|
|
to <command>setfmac</command>. This method will be explained
|
|
after all policies are covered.</para>
|
|
|
|
<sect2>
|
|
<title>Planning Mandatory Sensitivity</title>
|
|
|
|
<para>When using the MLS policy module, an administrator plans
|
|
to control the flow of sensitive information. The default
|
|
<literal>block read up block write down</literal> sets
|
|
everything to a low state. Everything is accessible and an
|
|
administrator slowly augments the confidentiality of the
|
|
information during the configuration stage;.</para>
|
|
|
|
<para>Beyond the three basic label options, 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 using descriptive words, such
|
|
as classifications of <literal>Confidential</literal>,
|
|
<literal>Secret</literal>, and <literal>Top Secret</literal>.
|
|
Some administrators instead create different groups based on
|
|
project levels. Regardless of the classification method, a
|
|
well thought out plan must exist before implementing such a
|
|
restrictive policy.</para>
|
|
|
|
<para>Some example situations for the MLS policy module
|
|
include an e-commerce web server, a file server holding
|
|
critical company information, and financial institution
|
|
environments.</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 is similar to the
|
|
<acronym>MLS</acronym> policy with the exception that the rules
|
|
for information flow are slightly reversed. This is to prevent
|
|
the downward flow of sensitive information whereas the
|
|
<acronym>MLS</acronym> policy prevents the upward flow of
|
|
sensitive information. 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
|
|
hierarchical grades and non-hierarchical components. As an
|
|
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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Hierarchical integrity level with a set of non
|
|
hierarchical integrity categories.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fixed rules are <literal>no write up, no read
|
|
down</literal>, the 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 by 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><varname>security.mac.biba.enabled</varname> is used
|
|
to enable or disable enforcement of the Biba policy on the
|
|
target machine.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.biba.ptys_equal</varname> is
|
|
used to disable the Biba policy on &man.pty.4;
|
|
devices.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.biba.revocation_enabled</varname>
|
|
forces 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
|
|
<command>setfmac</command> and
|
|
<command>getfmac</command>:</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, which is 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 or 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 may
|
|
see and invoke while assuring that the programs and files are
|
|
free from threats and trusted by the system for that
|
|
user.</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 to 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, 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. Other users would be grouped into
|
|
other categories such as testers, designers, or end users and
|
|
would only be permitted read access.</para>
|
|
|
|
<para>A lower integrity subject is unable to write to a higher
|
|
integrity subject and 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, a
|
|
development and test machine, and a 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 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 <literal>[auxgrade]</literal>. When assigning
|
|
a LOMAC policy with an auxiliary grade, use the syntax
|
|
<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 using <literal>[auxgrade]</literal>. 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,
|
|
<command>setfmac</command> and <command>setpmac</command>
|
|
are 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>The auxiliary grade <literal>low</literal> 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 implements a secure
|
|
environment using various <acronym>MAC</acronym> modules
|
|
with properly configured policies. This is only a test as
|
|
implementing a policy and ignoring it could be disastrous in a
|
|
production environment.</para>
|
|
|
|
<para>Before beginning this process, <option>multilabel</option>
|
|
must be set on each file system as not doing so will result in
|
|
errors. This example assumes that <filename
|
|
role="package">net-mngt/nagios-plugins</filename>,
|
|
<filename role="package">net-mngt/nagios</filename>, and
|
|
<filename role="package">www/apache22</filename> 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 <filename>/etc/login.conf</filename>:</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>Add the following line to the default user class:</para>
|
|
|
|
<programlisting>:label=biba/high:</programlisting>
|
|
|
|
<para>Next, issue the following command to rebuild the
|
|
database:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Boot Configuration</title>
|
|
|
|
<para>Add the following lines to
|
|
<filename>/boot/loader.conf</filename>:</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 >= 1001) && ($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 as
|
|
<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 enforces security by setting restrictions
|
|
on the flow of information. In this specific configuration,
|
|
users, including <username>root</username>, 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 will be read by the 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 will differ depending
|
|
upon the environment and must be run on every file
|
|
system.</para>
|
|
</note>
|
|
|
|
<para><filename>/etc/mac.conf</filename> 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>,
|
|
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:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cd /etc/mail && make stop && \
|
|
setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \
|
|
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 for error messages.
|
|
Use &man.sysctl.8; to disable the &man.mac.biba.4; security
|
|
policy module enforcement and try starting everything again as
|
|
usual.</para>
|
|
|
|
<note>
|
|
<para>The <username>root</username> user can still change the
|
|
security enforcement and edit its configuration files. 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 using &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, set 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 storage system
|
|
with fewer than fifty users. Users will have login
|
|
capabilities, and be permitted to store data and access
|
|
resources.</para>
|
|
|
|
<para>For this scenario, the &man.mac.bsdextended.4; and
|
|
&man.mac.seeotheruids.4; policy modules could co-exist and block
|
|
access to system objects while hiding user processes.</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 by adding this line to
|
|
<filename>/etc/rc.conf</filename>:</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 lines in order to 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 <command>ps aux</command> to see if processes
|
|
of other users are visible. Verify that running &man.ls.1; on
|
|
another user's home directory fails.</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, unload the security policy module and reload it again
|
|
using &man.kldunload.8; and &man.kldload.8;.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="mac-troubleshoot">
|
|
<title>Troubleshooting the MAC Framework</title>
|
|
|
|
<indexterm>
|
|
<primary>MAC Troubleshooting</primary>
|
|
</indexterm>
|
|
|
|
<para>This section discusses common configuration issues.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The <option>multilabel</option> flag does not stay
|
|
enabled on my root (<filename>/</filename>) partition!</para>
|
|
|
|
<para>The following steps may resolve this transient
|
|
error:</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Edit <filename>/etc/fstab</filename> and set the root
|
|
partition to <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.</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
|
|
<command>mount</command> to ensure that
|
|
<option>multilabel</option> has been properly set on the
|
|
root file system.</para>
|
|
</step>
|
|
</procedure>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>After establishing a secure environment with
|
|
<acronym>MAC</acronym>, I am no longer able to start
|
|
Xorg!</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 <command>cap_mkdb</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, the Xorg
|
|
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 the environment to
|
|
the &a.questions; mailing list.</para>
|
|
</step>
|
|
</procedure>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The error: <errorname>_secure_path: unable to stat
|
|
.login_conf</errorname> shows up.</para>
|
|
|
|
<para>When a user attempts to switch from the
|
|
<username>root</username> user to another user in the system,
|
|
the error message <errorname>_secure_path: unable to stat
|
|
.login_conf</errorname> appears.</para>
|
|
|
|
<para>This message is usually shown when the user has a higher
|
|
label setting than that of the user they are attempting to
|
|
become. For instance, <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
|
|
whether or not <username>root</username> has used
|
|
<command>su</command> to become <username>joe</username> as
|
|
the Biba integrity model will not permit
|
|
<username>root</username> to view objects set at a lower
|
|
integrity level.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The system no longer recognizes the
|
|
<username>root</username> user.</para>
|
|
|
|
<para>In normal or even single user mode, the
|
|
<username>root</username> is not recognized,
|
|
<command>whoami</command> returns 0 (zero), and
|
|
<command>su</command> returns <errorname>who are
|
|
you?</errorname>.</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 disabled, the login capabilities database
|
|
needs to be reconfigured with <option>label</option> removed.
|
|
Double check <filename>login.conf</filename> to ensure that
|
|
all <option>label</option> options have been removed and
|
|
rebuild the database with <command>cap_mkdb</command>.</para>
|
|
|
|
<para>This may also happen if a policy restricts access to
|
|
<filename>master.passwd</filename>. This is 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 using &man.sysctl.8; and
|
|
everything should return to normal.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
</chapter>
|