1776 lines
68 KiB
XML
1776 lines
68 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
$FreeBSD$
|
|
-->
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
|
xml:id="mac">
|
|
<info>
|
|
<title>Mandatory Access Control</title>
|
|
|
|
<authorgroup>
|
|
<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Written
|
|
by </contrib></author>
|
|
</authorgroup>
|
|
</info>
|
|
|
|
<sect1 xml:id="mac-synopsis">
|
|
<title>Synopsis</title>
|
|
|
|
<indexterm><primary>MAC</primary></indexterm>
|
|
<indexterm>
|
|
<primary>Mandatory Access Control</primary>
|
|
<see>MAC</see>
|
|
</indexterm>
|
|
|
|
<para>&os; supports security extensions based on the
|
|
&posix;.1e draft. These security mechanisms include file system
|
|
Access Control Lists (<xref linkend="fs-acl"/>) and Mandatory
|
|
Access Control (<acronym>MAC</acronym>). <acronym>MAC</acronym>
|
|
allows access control modules to be loaded in order to implement
|
|
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>The terminology associated with the
|
|
<acronym>MAC</acronym> framework.</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>The considerations to take into account before
|
|
configuring a system to use the
|
|
<acronym>MAC</acronym> framework.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Which <acronym>MAC</acronym> security policy modules
|
|
are included in &os; and how to configure them.</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>
|
|
|
|
<para>While 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. Refer to &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.</para>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="mac-inline-glossary">
|
|
<title>Key Terms</title>
|
|
|
|
<para>The following key terms are used when referring to the
|
|
<acronym>MAC</acronym> framework:</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>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>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>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>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>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>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 object effectively means access to its data.</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>
|
|
|
|
<listitem>
|
|
<para><emphasis>policy</emphasis>: a collection of rules
|
|
which defines how objectives are to be achieved. A policy
|
|
usually documents how certain items are to be handled. This
|
|
chapter considers a policy to be 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>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>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>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>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 xml: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. When setting a label, the administrator must
|
|
understand its 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.</para>
|
|
|
|
<para>There are two types of label policies: single label and
|
|
multi label. By default, the system will use single label. The
|
|
administrator should be aware of the pros and cons of each in
|
|
order to implement policies which meet the requirements of the
|
|
system's security model.</para>
|
|
|
|
<para>A single label security policy only permits one label to be
|
|
used for every subject or object. Since a single label policy
|
|
enforces one set of access permissions across the entire system,
|
|
it provides lower administration overhead, but decreases the
|
|
flexibility of policies which support labeling. However, in
|
|
many environments, a single label policy may be all that is
|
|
required.</para>
|
|
|
|
<para>A single label policy is somewhat similar to
|
|
<acronym>DAC</acronym> as <systemitem
|
|
class="username">root</systemitem> configures the policies so
|
|
that users are placed in the appropriate categories and access
|
|
levels. A notable difference is that many policy modules can
|
|
also restrict <systemitem class="username">root</systemitem>.
|
|
Basic control over objects will then be released to the group,
|
|
but <systemitem class="username">root</systemitem> may revoke or
|
|
modify the settings at any time.</para>
|
|
|
|
<para>When appropriate, a multi label policy can be set on a
|
|
<acronym>UFS</acronym> file system by passing
|
|
<option>multilabel</option> to &man.tunefs.8;. A multi label
|
|
policy permits each subject or object to have its own
|
|
independent <acronym>MAC</acronym> label. The decision to use a
|
|
multi label or single label policy is only required for policies
|
|
which implement the labeling feature, such as
|
|
<literal>biba</literal>, <literal>lomac</literal>, and
|
|
<literal>mls</literal>. Some policies, such as
|
|
<literal>seeotheruids</literal>, <literal>portacl</literal> and
|
|
<literal>partition</literal>, do not use labels at all.</para>
|
|
|
|
<para>Using a multi label policy on a partition and establishing a
|
|
multi label security model can increase administrative overhead
|
|
as everything in that 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 specified <acronym>UFS</acronym> file system. 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 <xref
|
|
linkend="mac-troubleshoot"/>.</para>
|
|
</note>
|
|
|
|
<para>Since the multi label policy is set on a per-file system
|
|
basis, a multi label policy may not be needed if the file system
|
|
layout is well designed. Consider an example security
|
|
<acronym>MAC</acronym> model for a &os; web server. This
|
|
machine uses the single label, <literal>biba/high</literal>, for
|
|
everything in the default file systems. If the web server needs
|
|
to run at <literal>biba/low</literal> to prevent write up
|
|
capabilities, it could be installed to a separate
|
|
<acronym>UFS</acronym> <filename>/usr/local</filename> file
|
|
system set at <literal>biba/low</literal>.</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
|
|
<command>setfmac</command>, which is used to set
|
|
<acronym>MAC</acronym> labels on system objects, and
|
|
<command>setpmac</command>, which is used to set the labels on
|
|
system subjects. For example, to set the
|
|
<literal>biba</literal> <acronym>MAC</acronym> label to
|
|
<literal>high</literal> on <filename>test</filename>:</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 a restricted
|
|
object. 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, if a user running at
|
|
low integrity tries to change the label of a high integrity
|
|
file, or a user running at low integrity tries to change the
|
|
label of a low integrity file to a high integrity label, these
|
|
operations will fail.</para>
|
|
|
|
<para>The system administrator may use
|
|
<command>setpmac</command> to override the policy module's
|
|
settings by assigning a different label to the invoked
|
|
process:</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>For currently running processes, such as
|
|
<application>sendmail</application>,
|
|
<command>getpmac</command> is usually used instead. This
|
|
command takes a process ID (<acronym>PID</acronym>) in place
|
|
of a command name. 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.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Predefined Labels</title>
|
|
|
|
<para>A few &os; policy modules which support the labeling
|
|
feature offer three predefined labels: <literal>low</literal>,
|
|
<literal>equal</literal>, and <literal>high</literal>,
|
|
where:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>low</literal> 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><literal>equal</literal> sets the subject or object to
|
|
be disabled or unaffected and should only be placed on
|
|
objects considered to be exempt from the policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>high</literal> grants an object or subject
|
|
the highest setting available in the Biba and
|
|
<acronym>MLS</acronym> policy modules.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Such policy modules include &man.mac.biba.4;,
|
|
&man.mac.mls.4; and &man.mac.lomac.4;. Each of the predefined
|
|
labels establishes a different information flow directive.
|
|
Refer to the manual page of the module to determine the traits
|
|
of the generic label configurations.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Numeric Labels</title>
|
|
|
|
<para>The Biba and <acronym>MLS</acronym> policy modules support
|
|
a numeric label which 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. 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/Grade
|
|
10:Compartments 2, 3 and 6: (grade 5 ...</quote>)</para>
|
|
|
|
<para>In this example, the first grade would be considered the
|
|
effective grade with effective compartments, the second grade
|
|
is the low grade, and the last one is the high grade. In most
|
|
configurations, such fine-grained settings are not needed as
|
|
they are considered to be advanced configurations.</para>
|
|
|
|
<para>System objects only have a current grade and 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
|
|
<firstterm>dominance</firstterm>, 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>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>User Labels</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>/etc/login.conf</filename> using login classes.
|
|
Every policy module that uses labels will implement the user
|
|
class setting.</para>
|
|
|
|
<para>To set the user class default label which will be enforced
|
|
by <acronym>MAC</acronym>, add a <option>label</option> entry.
|
|
An example <option>label</option> entry containing every
|
|
policy module is displayed below. Note that in a real
|
|
configuration, 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>
|
|
|
|
<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>While users can not modify the default value, they 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
|
|
<literal>5</literal>, its maximum is <literal>15</literal>,
|
|
and the default effective label is <literal>10</literal>. The
|
|
process will run at <literal>10</literal> until it chooses to
|
|
change label, perhaps due to the user using
|
|
<command>setpmac</command>, which will be constrained by Biba
|
|
to the configured range.</para>
|
|
|
|
<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 can become difficult to manage.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Network Interface Labels</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
|
|
Biba, for example, will not be permitted to access network
|
|
interfaces with a label of <literal>low</literal>.</para>
|
|
|
|
<para>When setting the <acronym>MAC</acronym> label on network
|
|
interfaces, <option>maclabel</option> may be passed to
|
|
<command>ifconfig</command>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ifconfig bge0 maclabel biba/equal</userinput></screen>
|
|
|
|
<para>This example will set the <acronym>MAC</acronym> label of
|
|
<literal>biba/equal</literal> on the <literal>bge0</literal>
|
|
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 the rest of this chapter for
|
|
more information on those tunables.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="mac-planning">
|
|
<title>Planning the Security Configuration</title>
|
|
|
|
<para>Before implementing any <acronym>MAC</acronym> policies, a
|
|
planning phase is recommended. During the planning stages, an
|
|
administrator should consider the implementation requirements
|
|
and goals, such as:</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> modules will be required to
|
|
achieve this goal.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>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. Since different environments have different needs and
|
|
requirements, establishing a complete security profile will
|
|
decrease the need of changes once the system goes live.</para>
|
|
|
|
<para>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 control of the
|
|
<acronym>MAC</acronym> access rules is 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>
|
|
|
|
<para> The rest of this chapter covers the available modules,
|
|
describes their use and configuration, and in some cases,
|
|
provides insight on applicable situations.</para>
|
|
|
|
<caution>
|
|
<para>Implementing <acronym>MAC</acronym> is much like
|
|
implementing a firewall since 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> over a remote
|
|
connection should be done with extreme caution.</para>
|
|
</caution>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="mac-policies">
|
|
<title>Available MAC Policies</title>
|
|
|
|
<para>The default &os; kernel
|
|
includes <literal>options MAC</literal>. This means that every
|
|
module included with the <acronym>MAC</acronym> framework can be
|
|
loaded with <command>kldload</command> as a run-time kernel
|
|
module. After testing the module, 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>&os; includes a group of policies that will cover most
|
|
security requirements. Each policy is summarized below. The
|
|
last three policies support integer settings in place of the
|
|
three default labels.</para>
|
|
|
|
<sect2 xml: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 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 other modules.</para>
|
|
|
|
<para>After loading the module, the following
|
|
<command>sysctl</command> tunables may be used to control its
|
|
features:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><varname>security.mac.seeotheruids.enabled</varname>
|
|
enables the module and implements 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 specified groups to be exempt from this policy. To
|
|
exempt specific groups, use the
|
|
<varname>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></varname>
|
|
<command>sysctl</command> tunable, replacing
|
|
<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>
|
|
</sect2>
|
|
|
|
<sect2 xml: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 a file system
|
|
firewall. It 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 using
|
|
<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>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 blocks all
|
|
access by users but leaves <systemitem
|
|
class="username">root</systemitem> unaffected:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen>
|
|
|
|
<para>While this rule is simple to implement, it is a very bad
|
|
idea as it blocks all users from issuing any commands. A
|
|
more realistic example blocks <systemitem
|
|
class="username">user1</systemitem> all access, including
|
|
directory listings, to <systemitem
|
|
class="username"><replaceable>user2</replaceable></systemitem>'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 <systemitem
|
|
class="username">user1</systemitem>, <option>not
|
|
uid <replaceable>user2</replaceable></option> could be used
|
|
in order to enforce the same access restrictions for all
|
|
users. However, the <systemitem
|
|
class="username">root</systemitem> user is unaffected by
|
|
these rules.</para>
|
|
|
|
<note>
|
|
<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>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 xml: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 is used to disable network
|
|
interfaces on the fly and to keep network interfaces from
|
|
being brought up during system boot. It does not use labels
|
|
and does not depend on any other
|
|
<acronym>MAC</acronym> modules.</para>
|
|
|
|
<para>Most of this module's control is performed through these
|
|
<command>sysctl</command> tunables:</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
|
|
use would be to write a script which uses an application such
|
|
as <package>security/aide</package> to automatically block
|
|
network traffic if it finds new or altered files in protected
|
|
directories.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml: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,
|
|
making it possible to allow non-<systemitem
|
|
class="username">root</systemitem> 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 <systemitem
|
|
class="username">root</systemitem> user from this
|
|
policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>security.mac.portacl.rules</varname>
|
|
specifies the policy as a text string of the form
|
|
<literal>rule[,rule,...]</literal>, with as many rules as
|
|
needed, and where each rule is of the form
|
|
<literal>idtype:id:protocol:port</literal>. The
|
|
<parameter>idtype</parameter> is either
|
|
<literal>uid</literal> or <literal>gid</literal>. The
|
|
<parameter>protocol</parameter> parameter can be
|
|
<literal>tcp</literal> or <literal>udp</literal>. The
|
|
<parameter>port</parameter> parameter is the port number
|
|
to allow the specified user or group to bind to. Only
|
|
numeric values can be used for the user ID, group ID,
|
|
and port parameters.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>By default, ports below 1024 can only be used by
|
|
privileged processes which run as <systemitem
|
|
class="username">root</systemitem>. For &man.mac.portacl.4;
|
|
to allow non-privileged processes to bind to ports below 1024,
|
|
set the following tunables as
|
|
follows:</para>
|
|
|
|
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
|
|
&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0</userinput>
|
|
&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|
|
|
<para>To prevent the <systemitem
|
|
class="username">root</systemitem> user from being affected
|
|
by this policy, set
|
|
<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>To allow the <systemitem class="username">www</systemitem>
|
|
user with <acronym>UID</acronym> 80 to bind to port 80
|
|
without ever needing <systemitem
|
|
class="username">root</systemitem> privilege:</para>
|
|
|
|
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen>
|
|
|
|
<para>This next example permits the user with the
|
|
<acronym>UID</acronym> of 1001 to bind to
|
|
<acronym>TCP</acronym> ports 110 (POP3) and 995
|
|
(POP3s):</para>
|
|
|
|
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
|
|
</sect2>
|
|
|
|
<sect2 xml: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 drops processes into
|
|
specific <quote>partitions</quote> based on their
|
|
<acronym>MAC</acronym> label. 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>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>
|
|
|
|
<screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
|
|
|
|
<para>This command displays the partition label and the process
|
|
list:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ps Zax</userinput></screen>
|
|
|
|
<para>This command displays 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 <systemitem
|
|
class="username">root</systemitem>'s label unless the
|
|
&man.mac.seeotheruids.4; policy is loaded.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 xml: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 levels can reach numbers greater than several
|
|
thousand, it would be a daunting task to thoroughly configure
|
|
every subject or object. To ease this administrative
|
|
overhead, three labels are included in this policy:
|
|
<literal>mls/low</literal>, <literal>mls/equal</literal>, and
|
|
<literal>mls/high</literal>, where:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>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 to a lower level.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>mls/equal</literal> should be placed on
|
|
objects which should be exempt from the policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>mls/high</literal> 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:</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 <acronym>MLS</acronym> labels, use
|
|
&man.setfmac.8;. To assign a label to an object:</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>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>getfmac test</userinput></screen>
|
|
|
|
<para>Another approach is to create a master policy file in
|
|
<filename>/etc/</filename> which specifies the
|
|
<acronym>MLS</acronym> policy information and to feed that
|
|
file to <command>setfmac</command>.</para>
|
|
|
|
<para>When using the <acronym>MLS</acronym> 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.</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 a
|
|
restrictive policy.</para>
|
|
|
|
<para>Some example situations for the <acronym>MLS</acronym>
|
|
policy module include an e-commerce web server, a file server
|
|
holding critical company information, and financial
|
|
institution environments.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml: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.</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 a
|
|
grade ascends, so does its integrity.</para>
|
|
|
|
<para>Supported labels are <literal>biba/low</literal>,
|
|
<literal>biba/equal</literal>, and
|
|
<literal>biba/high</literal>, where:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>biba/low</literal> is considered the lowest
|
|
integrity an object or subject may have. Setting this on
|
|
objects or subjects blocks their write access to objects
|
|
or subjects marked as <literal>biba/high</literal>, but
|
|
will not prevent read access.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>biba/equal</literal> should only be placed on
|
|
objects considered to be exempt from the policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>biba/high</literal> permits writing to
|
|
objects set at a lower label, but does 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 levels 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 <acronym>MLS</acronym>
|
|
sensitivity levels.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The following 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>
|
|
|
|
<para>Integrity, which is different from sensitivity, is used to
|
|
guarantee that information is not manipulated by untrusted
|
|
parties. This includes information passed between subjects
|
|
and objects. It ensures that users will only be able to
|
|
modify or access information they have been given explicit
|
|
access to. The &man.mac.biba.4; security policy module
|
|
permits an administrator to configure which files and programs
|
|
a user may see and invoke while assuring that the programs and
|
|
files are 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.
|
|
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 list
|
|
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>
|
|
|
|
<sect2 xml:id="mac-lomac">
|
|
<title>The MAC Low-watermark 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 Low-watermark integrity policy works almost
|
|
identically to Biba, 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 policy with
|
|
an auxiliary grade, use the syntax
|
|
<literal>lomac/10[2]</literal>, where
|
|
<literal>2</literal> is the auxiliary grade.</para>
|
|
|
|
<para>This 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 greater compatibility and require less initial
|
|
configuration than Biba.</para>
|
|
|
|
<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 lomac/high[low]</userinput></screen>
|
|
|
|
<para>The auxiliary grade <literal>low</literal> is a feature
|
|
provided only by the <acronym>MAC</acronym>
|
|
<acronym>LOMAC</acronym> policy.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml: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 are 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 <systemitem
|
|
class="username">root</systemitem> 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 xml:id="mac-implementing">
|
|
<title>Nagios in a MAC Jail</title>
|
|
|
|
<indexterm>
|
|
<primary>Nagios in a MAC Jail</primary>
|
|
</indexterm>
|
|
|
|
<para>This section demonstrates the steps that are needed to
|
|
implement the <application>Nagios</application> network
|
|
monitoring system in a <acronym>MAC</acronym> environment. This
|
|
is meant as an example which still requires the administrator to
|
|
test that the implemented policy meets the security requirements
|
|
of the network before using in a production environment.</para>
|
|
|
|
<para>This example requires <option>multilabel</option> to be set
|
|
on each file system. It also assumes that
|
|
<package>net-mgmt/nagios-plugins</package>,
|
|
<package>net-mgmt/nagios</package>, and
|
|
<package>www/apache22</package> are all installed, configured,
|
|
and working correctly before attempting the integration into the
|
|
<acronym>MAC</acronym> framework.</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>Then, add the following line to the default user class
|
|
section:</para>
|
|
|
|
<programlisting>:label=biba/high:</programlisting>
|
|
|
|
<para>Save the edits and issue the following command to rebuild
|
|
the database:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Configure Users</title>
|
|
|
|
<para>Set the <systemitem class="username">root</systemitem>
|
|
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 <systemitem
|
|
class="username">root</systemitem> will now require a login
|
|
class. The login class is required, otherwise users will be
|
|
refused access to common commands. 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>Next, drop the <systemitem
|
|
class="username">nagios</systemitem> and <systemitem
|
|
class="username">www</systemitem> accounts into the insecure
|
|
class:</para>
|
|
|
|
<screen>&prompt.root; <userinput>pw usermod nagios -L insecure</userinput>
|
|
&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
|
|
|
|
/dev/(/.*)? biba/equal
|
|
|
|
/var biba/equal
|
|
/var/spool(/.*)? biba/equal
|
|
|
|
/var/log(/.*)? biba/equal
|
|
|
|
/tmp(/.*)? biba/equal
|
|
/var/tmp(/.*)? biba/equal
|
|
|
|
/var/spool/mqueue biba/equal
|
|
/var/spool/clientmqueue biba/equal
|
|
|
|
# For Nagios:
|
|
/usr/local/etc/nagios(/.*)? biba/10
|
|
|
|
/var/spool/nagios(/.*)? biba/10
|
|
|
|
# For apache
|
|
/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 <systemitem
|
|
class="username">root</systemitem>, 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 after running
|
|
<command>setfsmac</command> on every file system. This
|
|
example sets the policy on the root file system:</para>
|
|
|
|
<screen>&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput></screen>
|
|
|
|
<para>Next, add these edits to the main section of
|
|
<filename>/etc/mac.conf</filename>:</para>
|
|
|
|
<programlisting>default_labels file ?biba
|
|
default_labels ifnet ?biba
|
|
default_labels process ?biba
|
|
default_labels socket ?biba</programlisting>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Loader Configuration</title>
|
|
|
|
<para>To finish the configuration, add the following lines to
|
|
<filename>/boot/loader.conf</filename>:</para>
|
|
|
|
<programlisting>mac_biba_load="YES"
|
|
mac_seeotheruids_load="YES"
|
|
security.mac.biba.trust_all_interfaces=1</programlisting>
|
|
|
|
<para>And the following line to the network card configuration
|
|
stored in <filename>/etc/rc.conf</filename>. If the primary
|
|
network 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>First, ensure that the web server and
|
|
<application>Nagios</application> will not be started on
|
|
system initialization and reboot. Ensure that <systemitem
|
|
class="username">root</systemitem> cannot access any of the
|
|
files in the <application>Nagios</application> configuration
|
|
directory. If <systemitem class="username">root</systemitem>
|
|
can list the contents of
|
|
<filename>/var/spool/nagios</filename>, something is wrong.
|
|
Instead, 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. If
|
|
needed, use &man.sysctl.8; to disable the &man.mac.biba.4;
|
|
security policy module and try starting everything again as
|
|
usual.</para>
|
|
|
|
<note>
|
|
<para>The <systemitem class="username">root</systemitem> 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 xml:id="mac-troubleshoot">
|
|
<title>Troubleshooting the MAC Framework</title>
|
|
|
|
<indexterm>
|
|
<primary>MAC Troubleshooting</primary>
|
|
</indexterm>
|
|
|
|
<para>This section discusses common configuration errors and how
|
|
to resolve them.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>The <option>multilabel</option> flag does not stay
|
|
enabled on the root (<filename>/</filename>)
|
|
partition:</term>
|
|
|
|
<listitem>
|
|
<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>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>After establishing a secure environment with
|
|
<acronym>MAC</acronym>, <application>Xorg</application> no
|
|
longer starts:</term>
|
|
<listitem>
|
|
<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 that the label policies are set
|
|
correctly for the user,
|
|
<application>Xorg</application>, and the
|
|
<filename>/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;.</para>
|
|
</step>
|
|
</procedure>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>The <errorname>_secure_path: unable to stat
|
|
.login_conf</errorname> error appears:</term>
|
|
<listitem>
|
|
<para>This error can appear when a user attempts to switch
|
|
from the <systemitem class="username">root</systemitem>
|
|
user to another user in the system. This message
|
|
usually occurs when the user has a higher label setting
|
|
than that of the user they are attempting to become.
|
|
For instance, if <systemitem
|
|
class="username">joe</systemitem> has a default label
|
|
of <option>biba/low</option> and <systemitem
|
|
class="username">root</systemitem> has a label of
|
|
<option>biba/high</option>, <systemitem
|
|
class="username">root</systemitem> cannot view
|
|
<systemitem class="username">joe</systemitem>'s home
|
|
directory. This will happen whether or not <systemitem
|
|
class="username">root</systemitem> has used
|
|
<command>su</command> to become <systemitem
|
|
class="username">joe</systemitem> as the Biba
|
|
integrity model will not permit <systemitem
|
|
class="username">root</systemitem> to view objects set
|
|
at a lower integrity level.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>The system no longer recognizes <systemitem
|
|
class="username">root</systemitem>:</term>
|
|
<listitem>
|
|
<para>When this occurs, <command>whoami</command> returns
|
|
<literal>0</literal> and <command>su</command> returns
|
|
<errorname>who are you?</errorname>.</para>
|
|
|
|
<para>This can happen if a labeling policy has been
|
|
disabled by &man.sysctl.8; or the policy module was
|
|
unloaded. If the policy is disabled, the login
|
|
capabilities database needs to be reconfigured. Double
|
|
check <filename>/etc/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>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect1>
|
|
</chapter>
|