Editorial review of Available MAC Policies.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
16e8132f17
commit
94d3851b1f
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44374
1 changed files with 156 additions and 260 deletions
|
|
@ -552,13 +552,10 @@ test: biba/high</screen>
|
|||
<sect1 xml:id="mac-planning">
|
||||
<title>Planning the Security Configuration</title>
|
||||
|
||||
<para>Whenever a new technology is implemented, a planning phase
|
||||
<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 the
|
||||
implementation goals.</para>
|
||||
|
||||
<para>For <acronym>MAC</acronym> installations, these
|
||||
include:</para>
|
||||
should consider the implementation requirements and
|
||||
goals, such as:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -573,29 +570,19 @@ test: biba/high</screen>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Which <acronym>MAC</acronym> module or modules will be
|
||||
<para>Which <acronym>MAC</acronym> 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
|
||||
<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. 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
|
||||
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. 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>
|
||||
goes live.</para>
|
||||
|
||||
<para>Consider how the
|
||||
<acronym>MAC</acronym> framework augments the security of
|
||||
|
|
@ -624,8 +611,8 @@ test: biba/high</screen>
|
|||
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
|
||||
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
|
||||
|
|
@ -659,47 +646,37 @@ test: biba/high</screen>
|
|||
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, care must be taken to prevent being
|
||||
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> remotely should be
|
||||
implementation of <acronym>MAC</acronym> over a remote connection should be
|
||||
done with extreme caution.</para>
|
||||
</caution>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml: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 xml:id="mac-policies">
|
||||
<title>Available MAC Policies</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 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 discussed below.</para>
|
||||
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>
|
||||
|
|
@ -716,21 +693,21 @@ test: biba/high</screen>
|
|||
<para>Boot option:
|
||||
<literal>mac_seeotheruids_load="YES"</literal></para>
|
||||
|
||||
<para>The &man.mac.seeotheruids.4; module mimics and extends
|
||||
<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 the other modules.</para>
|
||||
operate transparently with other modules.</para>
|
||||
|
||||
<para>After loading the module, the following
|
||||
<command>sysctl</command> tunables may be used to control the
|
||||
<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 uses the default settings which
|
||||
enables the module and implements the default settings which
|
||||
deny users the ability to view processes and sockets owned
|
||||
by other users.</para>
|
||||
</listitem>
|
||||
|
|
@ -738,10 +715,10 @@ test: biba/high</screen>
|
|||
<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
|
||||
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. Replace
|
||||
<command>sysctl</command> tunable, replacing
|
||||
<replaceable>XXX</replaceable> with the numeric group ID
|
||||
to be exempted.</para>
|
||||
</listitem>
|
||||
|
|
@ -773,15 +750,15 @@ test: biba/high</screen>
|
|||
<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
|
||||
<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
|
||||
by the use of a &man.sysctl.8; parameter,
|
||||
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
|
||||
|
|
@ -792,13 +769,6 @@ test: biba/high</screen>
|
|||
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>
|
||||
|
||||
<sect3>
|
||||
<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>
|
||||
|
|
@ -807,17 +777,15 @@ test: biba/high</screen>
|
|||
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 <systemitem
|
||||
class="username">root</systemitem> unaffected, run the
|
||||
following command:</para>
|
||||
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>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
|
||||
<systemitem class="username">user1</systemitem> any and all
|
||||
<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>
|
||||
|
|
@ -828,17 +796,15 @@ test: biba/high</screen>
|
|||
<para>Instead of <systemitem
|
||||
class="username">user1</systemitem>, <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>
|
||||
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>The <systemitem class="username">root</systemitem>
|
||||
user is unaffected by these changes.</para>
|
||||
</note>
|
||||
|
||||
<para>For more information, refer to &man.mac.bsdextended.4;
|
||||
and &man.ugidfw.8;</para>
|
||||
</sect3>
|
||||
<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">
|
||||
|
|
@ -855,26 +821,26 @@ test: biba/high</screen>
|
|||
<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
|
||||
<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 the
|
||||
<command>sysctl</command> tunables listed below.</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>
|
||||
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>
|
||||
Filter interface, &man.bpf.4;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -887,7 +853,7 @@ test: biba/high</screen>
|
|||
<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
|
||||
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>
|
||||
|
|
@ -908,9 +874,8 @@ test: biba/high</screen>
|
|||
<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-<systemitem
|
||||
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>
|
||||
|
||||
|
|
@ -939,76 +904,54 @@ test: biba/high</screen>
|
|||
|
||||
<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:
|
||||
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> 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>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.</para>
|
||||
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>
|
||||
|
||||
<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 <systemitem
|
||||
<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,
|
||||
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>
|
||||
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
|
||||
net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
||||
&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0</userinput>
|
||||
&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
||||
|
||||
<para>See the examples below or refer to &man.mac.portacl.4; for
|
||||
further information.</para>
|
||||
|
||||
<sect3>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>Since the <systemitem class="username">root</systemitem>
|
||||
user should not be crippled by this policy, this example
|
||||
starts by setting the
|
||||
<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>Next, allow the user with <acronym>UID</acronym> 80
|
||||
to bind to port 80. This allows the <systemitem
|
||||
class="username">www</systemitem> user to run a web server
|
||||
without ever having <systemitem
|
||||
class="username">root</systemitem> privilege.</para>
|
||||
<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>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>
|
||||
<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>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="mac-partition">
|
||||
|
|
@ -1025,13 +968,9 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
<para>Boot option:
|
||||
<literal>mac_partition_load="YES"</literal></para>
|
||||
|
||||
<para>The &man.mac.partition.4; policy will drop processes into
|
||||
<para>The &man.mac.partition.4; policy drops 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
|
||||
<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>
|
||||
|
||||
|
|
@ -1051,26 +990,20 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
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>
|
||||
|
||||
<sect3>
|
||||
<title>Examples</title>
|
||||
<screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
|
||||
|
||||
<para>The following command will display the partition label
|
||||
<para>This command displays 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
|
||||
<para>This command displays another user's process
|
||||
partition label and that user's currently running
|
||||
processes:</para>
|
||||
|
||||
|
|
@ -1081,19 +1014,6 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
class="username">root</systemitem>'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>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="mac-mls">
|
||||
|
|
@ -1116,37 +1036,32 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
<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>
|
||||
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>The <literal>mls/low</literal> label contains a low
|
||||
configuration which permits it to be dominated by all
|
||||
other objects. Anything labeled with
|
||||
<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 on to
|
||||
them.</para>
|
||||
clearance level from writing or passing information to a
|
||||
lower level.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <literal>mls/equal</literal> label should be
|
||||
placed on objects considered to be exempt from the
|
||||
<para><literal>mls/equal</literal> should be
|
||||
placed on objects which should be exempt from the
|
||||
policy.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <literal>mls/high</literal> label is the highest
|
||||
<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
|
||||
|
|
@ -1158,8 +1073,8 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A hierarchical security level with a set of non
|
||||
hierarchical categories.</para>
|
||||
<para>A hierarchical security level with a set of
|
||||
non-hierarchical categories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1167,7 +1082,7 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
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>
|
||||
objects on its own level or above, but not beneath.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1183,8 +1098,7 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
</itemizedlist>
|
||||
|
||||
<para>The following <command>sysctl</command> tunables are
|
||||
available for the configuration of special services and
|
||||
interfaces:</para>
|
||||
available:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -1212,32 +1126,27 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
</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>
|
||||
<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>, issue the following command:</para>
|
||||
<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>. This method will be
|
||||
explained after all policies are covered.</para>
|
||||
file to <command>setfmac</command>.</para>
|
||||
|
||||
<sect3>
|
||||
<title>Planning Mandatory Sensitivity</title>
|
||||
|
||||
<para>When using the MLS policy module, an administrator plans
|
||||
<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 during the configuration stage;.</para>
|
||||
information.</para>
|
||||
|
||||
<para>Beyond the three basic label options, an administrator
|
||||
may group users and groups as required to block the
|
||||
|
|
@ -1248,14 +1157,13 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
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
|
||||
plan must exist before implementing a restrictive
|
||||
policy.</para>
|
||||
|
||||
<para>Some example situations for the MLS policy module
|
||||
<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>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="mac-biba">
|
||||
|
|
@ -1277,36 +1185,35 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
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>
|
||||
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 an
|
||||
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>; as explained below:</para>
|
||||
<literal>biba/high</literal>, where:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The <literal>biba/low</literal> label is considered
|
||||
<para><literal>biba/low</literal> 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>
|
||||
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>The <literal>biba/equal</literal> label should only be
|
||||
<para><literal>biba/equal</literal> 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
|
||||
<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>
|
||||
|
|
@ -1317,8 +1224,8 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Hierarchical integrity level with a set of non
|
||||
hierarchical integrity categories.</para>
|
||||
<para>Hierarchical integrity levels with a set of
|
||||
non-hierarchical integrity categories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1336,12 +1243,12 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Integrity levels instead of MLS sensitivity
|
||||
<para>Integrity levels instead of <acronym>MLS</acronym> sensitivity
|
||||
levels.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The following <command>sysctl</command> tunables can be
|
||||
<para>The following tunables can be
|
||||
used to manipulate the Biba policy:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
|
@ -1372,26 +1279,20 @@ net.inet.ip.portrange.reservedhigh=0</userinput></screen>
|
|||
&prompt.root; <userinput>getfmac test</userinput>
|
||||
test: biba/low</screen>
|
||||
|
||||
<sect3>
|
||||
<title>Planning Mandatory Integrity</title>
|
||||
|
||||
<para>Integrity, which is different from sensitivity,
|
||||
guarantees that the information will never be manipulated by
|
||||
<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, 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
|
||||
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 free from threats and trusted by the system for that
|
||||
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. Users will be blocked access not only to data but to
|
||||
programs and utilities both before and after they start.
|
||||
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.
|
||||
|
|
@ -1405,7 +1306,7 @@ test: biba/low</screen>
|
|||
|
||||
<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
|
||||
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
|
||||
|
|
@ -1413,11 +1314,10 @@ test: biba/low</screen>
|
|||
A less useful implementation would be a personal
|
||||
workstation, a machine used as a router, or a network
|
||||
firewall.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="mac-lomac">
|
||||
<title>The MAC LOMAC Module</title>
|
||||
<title>The MAC Low-watermark Module</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>MAC LOMAC</primary>
|
||||
|
|
@ -1435,38 +1335,34 @@ test: biba/low</screen>
|
|||
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
|
||||
<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 LOMAC policy with an auxiliary grade, use the
|
||||
syntax <literal>lomac/10[2]</literal> where the number two
|
||||
(2) is the auxiliary grade.</para>
|
||||
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>The <acronym>MAC</acronym> LOMAC policy relies on the
|
||||
<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 for
|
||||
<literal>[auxgrade]</literal>. The policy may provide
|
||||
greater compatibility and require less initial configuration
|
||||
than Biba.</para>
|
||||
|
||||
<sect3>
|
||||
<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>
|
||||
&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> LOMAC
|
||||
provided only by the <acronym>MAC</acronym> <acronym>LOMAC</acronym>
|
||||
policy.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue