svn commit: r44375 - head/en_US.ISO8859-1/books/handbook/mac
Dru Lavigne
dru at FreeBSD.org
Fri Mar 28 16:58:45 UTC 2014
Author: dru
Date: Fri Mar 28 16:58:45 2014
New Revision: 44375
URL: http://svnweb.freebsd.org/changeset/doc/44375
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri Mar 28 15:55:53 2014 (r44374)
+++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri Mar 28 16:58:45 2014 (r44375)
@@ -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>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>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
@@ -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>
-
- <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>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>
+ <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>
@@ -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>
-
- <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>
+ <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>
+ <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>
+
+ <para>This command displays another user's process partition
+ label and that user's currently running processes:</para>
- <screen>&prompt.root; <userinput>ps Zax</userinput></screen>
+ <screen>&prompt.root; <userinput>ps -ZU trhodes</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>
+ <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>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>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">
@@ -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>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>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">
@@ -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>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>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>
+ <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>
More information about the svn-doc-head
mailing list