White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
94d3851b1f
commit
91c1863bde
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44375
1 changed files with 228 additions and 239 deletions
|
|
@ -552,10 +552,10 @@ test: biba/high</screen>
|
|||
<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>
|
||||
<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>
|
||||
|
|
@ -570,32 +570,30 @@ test: biba/high</screen>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Which <acronym>MAC</acronym> modules will be
|
||||
required to achieve this goal.</para>
|
||||
<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>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>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
|
||||
|
|
@ -615,10 +613,10 @@ test: biba/high</screen>
|
|||
<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;
|
||||
<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
|
||||
|
|
@ -646,17 +644,17 @@ 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>
|
||||
<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>
|
||||
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>
|
||||
|
||||
|
|
@ -664,14 +662,14 @@ test: biba/high</screen>
|
|||
<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
|
||||
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>
|
||||
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
|
||||
|
|
@ -693,8 +691,8 @@ test: biba/high</screen>
|
|||
<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
|
||||
<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
|
||||
|
|
@ -707,9 +705,9 @@ test: biba/high</screen>
|
|||
<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>
|
||||
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>
|
||||
|
|
@ -750,15 +748,14 @@ test: biba/high</screen>
|
|||
<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
|
||||
<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
|
||||
|
|
@ -769,41 +766,43 @@ test: biba/high</screen>
|
|||
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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
|
|
@ -821,10 +820,10 @@ test: biba/high</screen>
|
|||
<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
|
||||
<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
|
||||
|
|
@ -853,8 +852,8 @@ 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
|
||||
use would be to write a script which uses an application such as
|
||||
<package>security/aide</package> to automatically block
|
||||
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>
|
||||
|
|
@ -904,19 +903,18 @@ test: biba/high</screen>
|
|||
|
||||
<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
|
||||
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
|
||||
<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>
|
||||
and port parameters.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -931,27 +929,27 @@ test: biba/high</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>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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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">
|
||||
|
|
@ -970,9 +968,10 @@ test: biba/high</screen>
|
|||
|
||||
<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>
|
||||
<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>
|
||||
|
|
@ -998,22 +997,21 @@ test: biba/high</screen>
|
|||
|
||||
<screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
|
||||
|
||||
<para>This command displays the partition label
|
||||
and the process list:</para>
|
||||
<para>This command displays the partition label and the process
|
||||
list:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>ps Zax</userinput></screen>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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">
|
||||
|
|
@ -1036,36 +1034,33 @@ test: biba/high</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 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>
|
||||
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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
|
|
@ -1141,29 +1136,28 @@ test: biba/high</screen>
|
|||
<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>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>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>
|
||||
<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">
|
||||
|
|
@ -1198,23 +1192,22 @@ test: biba/high</screen>
|
|||
|
||||
<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>
|
||||
<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>
|
||||
<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
|
||||
<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>
|
||||
|
|
@ -1243,13 +1236,13 @@ test: biba/high</screen>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Integrity levels instead of <acronym>MLS</acronym> sensitivity
|
||||
levels.</para>
|
||||
<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>
|
||||
<para>The following tunables can be used to manipulate the Biba
|
||||
policy:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -1279,41 +1272,38 @@ test: biba/high</screen>
|
|||
&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>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>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>
|
||||
<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">
|
||||
|
|
@ -1335,34 +1325,33 @@ test: biba/low</screen>
|
|||
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
|
||||
<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>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>
|
||||
<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>
|
||||
<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>
|
||||
<para>The auxiliary grade <literal>low</literal> is a feature
|
||||
provided only by the <acronym>MAC</acronym>
|
||||
<acronym>LOMAC</acronym> policy.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue