aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/handbook/mac
diff options
context:
space:
mode:
authorGabor Kovesdan <gabor@FreeBSD.org>2013-02-18 15:29:06 +0000
committerGabor Kovesdan <gabor@FreeBSD.org>2013-02-18 15:29:06 +0000
commit3ab2d87bc1fdf695c06d9b88641c96fbbf87baba (patch)
tree3a0150cc96d2a69b6f851e7c64066691c43c6383 /en_US.ISO8859-1/books/handbook/mac
parent28d065247c427ed8d21974efc5c1ffc0945666c8 (diff)
parent193a55160a83348d922e413a188a90c0f731e0fb (diff)
downloaddoc-3ab2d87bc1fdf695c06d9b88641c96fbbf87baba.tar.gz
doc-3ab2d87bc1fdf695c06d9b88641c96fbbf87baba.zip
- MFH
Notes
Notes: svn path=/projects/xml-tools/; revision=41007
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/mac')
-rw-r--r--en_US.ISO8859-1/books/handbook/mac/chapter.xml1614
1 files changed, 724 insertions, 890 deletions
diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
index 5bce8a18d0..facf372522 100644
--- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml
@@ -27,44 +27,42 @@
</indexterm>
<para>&os;&nbsp;5.X introduced new security extensions from the
- TrustedBSD project based on the &posix;.1e draft. Two of the
+ <ulink url="http://www.trustedbsd.org">TrustedBSD
+ Project</ulink> based on the &posix;.1e draft. Two of the
most significant new security mechanisms are file system Access
Control Lists (<acronym>ACL</acronym>s) and Mandatory Access
- Control (<acronym>MAC</acronym>) facilities. Mandatory Access
- Control allows new access control modules to be loaded,
- implementing new security policies. Some provide protections
- of a narrow subset of the system, hardening a particular
- service. Others provide comprehensive labeled security across
- all subjects and objects. The mandatory part of the definition
- comes from the fact that the enforcement of the controls is
- done by administrators and the system, and is not left up to
- the discretion of users as is done with discretionary access
- control (<acronym>DAC</acronym>, the standard file and System
- V <acronym>IPC</acronym> permissions on &os;).</para>
-
- <para>This chapter will focus on the
- Mandatory Access Control Framework (<acronym>MAC</acronym>
- Framework), and a set of pluggable security policy modules
- enabling various security mechanisms.</para>
+ Control (<acronym>MAC</acronym>) facilities. MAC allows new
+ access control modules to be loaded, implementing new security
+ policies. Some modules provide protections for a narrow subset
+ of the system, hardening a particular service. Others provide
+ comprehensive labeled security across all subjects and objects.
+ The mandatory part of the definition indicates that enforcement
+ of controls is performed by administrators and the operating
+ system. This is in contrast to the default security mechanism
+ of Discretionary Access Control (<acronym>DAC</acronym> where
+ enforcement is left to the discretion of users.</para>
+
+ <para>This chapter focuses on the <acronym>MAC</acronym> framework
+ and the set of pluggable security policy modules &os; provides
+ for enabling various security mechanisms.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
- <para>What <acronym>MAC</acronym> security policy modules
- are currently included in &os; and their associated
- mechanisms.</para>
+ <para>Which <acronym>MAC</acronym> security policy modules
+ are included in &os; and their associated mechanisms.</para>
</listitem>
<listitem>
- <para>What <acronym>MAC</acronym> security policy modules
- implement as well as the difference between a labeled and
- non-labeled policy.</para>
+ <para>The capabilities of <acronym>MAC</acronym> security
+ policy modules as well as the difference between a labeled
+ and non-labeled policy.</para>
</listitem>
<listitem>
- <para>How to efficiently configure a system to use
- the <acronym>MAC</acronym> framework.</para>
+ <para>How to efficiently configure a system to use the
+ <acronym>MAC</acronym> framework.</para>
</listitem>
<listitem>
@@ -74,8 +72,7 @@
<listitem>
<para>How to implement a more secure environment using the
- <acronym>MAC</acronym> framework and the examples
- shown.</para>
+ <acronym>MAC</acronym> framework.</para>
</listitem>
<listitem>
@@ -94,36 +91,27 @@
</listitem>
<listitem>
- <para>Be familiar with
- the basics of kernel configuration/compilation
- (<xref linkend="kernelconfig"/>).</para>
- </listitem>
-
- <listitem>
<para>Have some familiarity with security and how it
pertains to &os; (<xref linkend="security"/>).</para>
</listitem>
</itemizedlist>
<warning>
- <para>The improper use of the
- information contained herein may cause loss of system access,
- aggravation of users, or inability to access the features
- provided by X11. More importantly, <acronym>MAC</acronym>
- should not be relied upon to completely secure a system. The
- <acronym>MAC</acronym> framework only augments existing
- security policy; without sound security practices and
- regular security checks, the system will never be completely
- secure.</para>
-
- <para>It should also be noted that the examples contained
- within this chapter are just that, examples. It is not
- recommended that these particular settings be rolled out
- on a production system. Implementing the various security
- policy modules takes a good deal of thought and testing. One
- who does not fully understand exactly how everything works
- may find him or herself going back through the entire system
- and reconfiguring many files or directories.</para>
+ <para>Improper <acronym>MAC</acronym> configuration may cause
+ loss of system access, aggravation of users, or inability to
+ access the features provided by
+ <application>Xorg</application>. More importantly,
+ <acronym>MAC</acronym> should not be relied upon to completely
+ secure a system. The <acronym>MAC</acronym> framework only
+ augments an existing security policy. Without sound security
+ practices and regular security checks, the system will never
+ be completely secure.</para>
+
+ <para>The examples contained within this chapter are for
+ demonstration purposes and the example settings should
+ <emphasis>not</emphasis> be implemented on a production
+ system. Implementing any security policy takes a good deal of
+ understanding, proper design, and thorough testing.</para>
</warning>
<sect2>
@@ -135,10 +123,10 @@
modules will not be covered. A number of security policy
modules included with the <acronym>MAC</acronym> framework
have specific characteristics which are provided for both
- testing and new module development. These include the
+ testing and new module development. These include
&man.mac.test.4;, &man.mac.stub.4; and &man.mac.none.4;.
For more information on these security policy modules and
- the various mechanisms they provide, please review the manual
+ the various mechanisms they provide, refer to their manual
pages.</para>
</sect2>
</sect1>
@@ -147,127 +135,117 @@
<title>Key Terms in This Chapter</title>
<para>Before reading this chapter, a few key terms must be
- explained. This will hopefully clear up any confusion that
- may occur and avoid the abrupt introduction of new terms
- and information.</para>
+ explained:</para>
<itemizedlist>
<listitem>
- <para><emphasis>compartment</emphasis>: A compartment is a
- set of programs and data to be partitioned or separated,
- where users are given explicit access to specific components
- of a system. Also, a compartment represents a grouping,
- such as a work group, department, project, or topic. Using
- compartments, it is possible to implement a need-to-know
- security policy.</para>
+ <para><emphasis>compartment</emphasis>: a set of programs and
+ data to be partitioned or separated, where users are given
+ explicit access to specific component of a system. A
+ compartment represents a grouping, such as a work group,
+ department, project, or topic. Compartments make it
+ possible to implement a need-to-know-basis security
+ policy.</para>
</listitem>
<listitem>
- <para><emphasis>high water mark</emphasis>: A high water mark
- policy is one which permits the raising of security levels
- for the purpose of accessing higher level information. In
- most cases, the original level is restored after the process
+ <para><emphasis>high-watermark</emphasis>: this type of
+ policy permits the raising of security levels for the
+ purpose of accessing higher level information. In most
+ cases, the original level is restored after the process
is complete. Currently, the &os; <acronym>MAC</acronym>
- framework does not have a policy for this, but the
- definition is included for completeness.</para>
+ framework does not include this type of policy.</para>
</listitem>
<listitem>
- <para><emphasis>integrity</emphasis>: Integrity, as a key
- concept, is the level of trust which can be placed on data.
- As the integrity of the data is elevated, so does the
- ability to trust that data.</para>
+ <para><emphasis>integrity</emphasis>: the level of trust which
+ can be placed on data. As the integrity of the data is
+ elevated, so does the ability to trust that data.</para>
</listitem>
<listitem>
- <para><emphasis>label</emphasis>: A label is a security
- attribute which can be applied to files, directories, or
- other items in the system. It could be considered a
- confidentiality stamp; when a label is placed on a file it
- describes the security properties for that specific
- file and will only permit access by files, users, resources,
- etc. with a similar security setting. The meaning and
- interpretation of label values depends on the policy
- configuration: while some policies might treat a label as
- representing the integrity or secrecy of an object, other
- policies might use labels to hold rules for access.</para>
+ <para><emphasis>label</emphasis>: a security attribute which
+ can be applied to files, directories, or other items in the
+ system. It could be considered a confidentiality stamp.
+ When a label is placed on a file, it describes the security
+ properties of that file and will only permit access by
+ files, users, and resources with a similar security setting.
+ The meaning and interpretation of label values depends on
+ the policy configuration. Some policies treat a label as
+ representing the integrity or secrecy of an object while
+ other policies might use labels to hold rules for
+ access.</para>
</listitem>
<listitem>
- <para><emphasis>level</emphasis>: The increased or decreased
+ <para><emphasis>level</emphasis>: the increased or decreased
setting of a security attribute. As the level increases,
its security is considered to elevate as well.</para>
</listitem>
<listitem>
- <para><emphasis>low water mark</emphasis>: A low water mark
- policy is one which permits lowering of the security levels
- for the purpose of accessing information which is less
- secure. In most cases, the original security level of the
- user is restored after the process is complete. The only
- security policy module in &os; to use this is
- &man.mac.lomac.4;.</para>
+ <para><emphasis>low-watermark</emphasis>: this type of
+ policy permits lowering security levels for the purpose of
+ accessing information which is less secure. In most cases,
+ the original security level of the user is restored after
+ the process is complete. The only security policy module in
+ &os; to use this is &man.mac.lomac.4;.</para>
</listitem>
<listitem>
- <para><emphasis>multilabel</emphasis>: The
- <option>multilabel</option> property is a file system option
- which can be set in single user mode using the
- &man.tunefs.8; utility, during the boot operation
- using the &man.fstab.5; file, or during the creation of
- a new file system. This option will permit an administrator
- to apply different <acronym>MAC</acronym> labels on
- different objects. This option only applies to security
- policy modules which support labeling.</para>
+ <para><emphasis>multilabel</emphasis>: this property is a file
+ system option which can be set in single user mode using
+ &man.tunefs.8;, during boot using &man.fstab.5;, or during
+ the creation of a new file system. This option permits
+ an administrator to apply different <acronym>MAC</acronym>
+ labels on different objects. This option only applies to
+ security policy modules which support labeling.</para>
</listitem>
<listitem>
- <para><emphasis>object</emphasis>: An object or system
- object is an entity through which information flows
- under the direction of a <emphasis>subject</emphasis>.
- This includes directories, files, fields, screens,
- keyboards, memory, magnetic storage, printers or any other
- data storage/moving device. Basically, an object is a data
- container or a system resource; access to an
- <emphasis>object</emphasis> effectively means access to the
- data.</para>
+ <para><emphasis>object</emphasis>: an entity through which
+ information flows under the direction of a
+ <emphasis>subject</emphasis>. This includes directories,
+ files, fields, screens, keyboards, memory, magnetic storage,
+ printers or any other data storage or moving device. An
+ object is a data container or a system resource. Access to
+ an <emphasis>object</emphasis> effectively means access to
+ its data.</para>
</listitem>
<listitem>
- <para><emphasis>policy</emphasis>: A collection of rules
+ <para><emphasis>policy</emphasis>: a collection of rules
which defines how objectives are to be achieved. A
<emphasis>policy</emphasis> usually documents how certain
- items are to be handled. This chapter will
- consider the term <emphasis>policy</emphasis> in this
- context as a <emphasis>security policy</emphasis>; i.e.
- a collection of rules which will control the flow of data
- and information and define whom will have access to that
- data and information.</para>
+ items are to be handled. This chapter considers the term
+ <emphasis>policy</emphasis> to be a <emphasis>security
+ policy</emphasis>, or a collection of rules which controls
+ the flow of data and information and defines who has access
+ to that data and information.</para>
</listitem>
<listitem>
- <para><emphasis>sensitivity</emphasis>: Usually used when
- discussing <acronym>MLS</acronym>. A sensitivity level is
- a term used to describe how important or secret the data
+ <para><emphasis>sensitivity</emphasis>: usually used when
+ discussing Multilevel Security <acronym>MLS</acronym>. A
+ sensitivity level describes how important or secret the data
should be. As the sensitivity level increases, so does the
- importance of the secrecy, or confidentiality of the
+ importance of the secrecy, or confidentiality, of the
data.</para>
</listitem>
<listitem>
- <para><emphasis>single label</emphasis>: A single label is
- when the entire file system uses one label to
- enforce access control over the flow of data. When a file
- system has this set, which is any time when the
- <option>multilabel</option> option is not set, all
- files will conform to the same label setting.</para>
+ <para><emphasis>single label</emphasis>: a policy where the
+ entire file system uses one label to enforce access control
+ over the flow of data. Whenever <option>multilabel</option>
+ is not set, all files will conform to the same label
+ setting.</para>
</listitem>
<listitem>
- <para><emphasis>subject</emphasis>: a subject is any
- active entity that causes information to flow between
- <emphasis>objects</emphasis>; e.g., a user, user process,
- system process, etc. On &os;, this is almost always a
+ <para><emphasis>subject</emphasis>: any active entity that
+ causes information to flow between
+ <emphasis>objects</emphasis> such as a user, user process,
+ or system process. On &os;, this is almost always a
thread acting in a process on behalf of a user.</para>
</listitem>
</itemizedlist>
@@ -280,99 +258,71 @@
<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, block users from
- accessing certain ports and sockets, and more. Perhaps the
- best use of the policy modules is to blend them together, by
- loading several security policy modules at a time for a
- multi-layered security environment. In a multi-layered security
- environment, multiple policy modules are in effect to keep
- security in check. This is different to a hardening policy,
- which typically hardens elements of a system that is used only
- for specific purposes. The only downside is administrative
- overhead in cases of multiple file system labels, setting
- network access control user by user, etc.</para>
-
- <para>These downsides are minimal when compared to the lasting
- effect of the framework; for instance, the ability to pick
- and choose which policies are required for a specific
- configuration keeps performance overhead down. The reduction
- of support for unneeded policies can increase the overall
- performance of the system as well as offer flexibility of
- choice. A good implementation would consider the overall
- security requirements and effectively implement the various
- security policy modules offered by the framework.</para>
-
- <para>Thus a system utilizing <acronym>MAC</acronym> features
- should at least guarantee that a user will not be permitted
- to change security attributes at will; all user utilities,
- programs and scripts must work within the constraints of
- the access rules provided by the selected security policy
- modules; and that total control of the <acronym>MAC</acronym>
- access rules are in the hands of the system
- administrator.</para>
-
- <para>It is the sole duty of the system administrator to
- carefully select the correct security policy modules. Some
- environments may need to limit access control over the network;
- in these cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and
- even &man.mac.biba.4; policy modules might make good starting
- points. In other cases, strict confidentiality of file system
- objects might be required. Policy modules such as
- &man.mac.bsdextended.4; and &man.mac.mls.4; exist for this
- purpose.</para>
+ to protect the network and file systems or to block users from
+ accessing certain ports and sockets. Perhaps the best use of
+ the policy modules is to load several security policy modules at
+ a time in order to provide a <acronym>MLS</acronym> environment.
+ This approach differs from a hardening policy, which typically
+ hardens elements of a system which are used only for specific
+ purposes. The downside to <acronym>MLS</acronym> is increased
+ administrative overhead.</para>
+
+ <para>The overhead is minimal when compared to the lasting effect
+ of a framework which provides the ability to pick and choose
+ which policies are required for a specific configuration and
+ which keeps performance overhead down. The reduction of support
+ for unneeded policies can increase the overall performance of
+ the system as well as offer flexibility of choice. A good
+ implementation would consider the overall security requirements
+ and effectively implement the various security policy modules
+ offered by the framework.</para>
+
+ <para>A system utilizing <acronym>MAC</acronym> guarantees that a
+ user will not be permitted to change security attributes at
+ will. All user utilities, programs, and scripts must work
+ within the constraints of the access rules provided by the
+ selected security policy modules and total control of the
+ <acronym>MAC</acronym> access rules are in the hands of the
+ system administrator.</para>
+
+ <para>It is the duty of the system administrator to
+ carefully select the correct security policy modules. For an
+ environment that needs to limit access control over the network,
+ the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4;
+ policy modules make good starting points. For an environment
+ where strict confidentiality of file system objects is required,
+ consider the &man.mac.bsdextended.4; and &man.mac.mls.4; policy
+ modules.</para>
<para>Policy decisions could be made based on network
- configuration. Perhaps only certain users should be permitted
- access to facilities provided by &man.ssh.1; to access the
- network or the Internet. The &man.mac.portacl.4; would be
- the policy module of choice for these situations. But what
- should be done in the case of file systems? Should all access
- to certain directories be severed from other groups or specific
- users? Or should we limit user or utility access to specific
- files by setting certain objects as classified?</para>
-
- <para>In the file system case, access to objects might be
- considered confidential to some users, but not to others.
- For an example, a large development team might be broken
- off into smaller groups of individuals. Developers in
- project A might not be permitted to access objects written
- by developers in project B. Yet they might need to access
- objects created by developers in project C; that is quite a
- situation indeed. Using the different security policy modules
- provided by the <acronym>MAC</acronym> framework; users could
- be divided into these groups and then given access to the
- appropriate areas without fear of information
- leakage.</para>
-
- <para>Thus, each security policy module has a unique way of
- dealing with the overall security of a system. Module selection
- should be based on a well thought out security policy. In many
- cases, the overall policy may need to be revised and
- reimplemented on the system. Understanding the different
+ configuration. If only certain users should be permitted
+ access to &man.ssh.1;, the &man.mac.portacl.4; policy module is
+ a good choice. In the case of file systems, access to objects
+ might be considered confidential to some users, but not to
+ others. As an example, a large development team might be
+ broken off into smaller projects where developers in project A
+ might not be permitted to access objects written by developers
+ in project B. Yet both projects might need to access objects
+ created by developers in project C. Using the different
+ security policy modules provided by the <acronym>MAC</acronym>
+ framework, users could be divided into these groups and then
+ given access to the appropriate objects.</para>
+
+ <para>Each security policy module has a unique way of dealing with
+ the overall security of a system. Module selection should be
+ based on a well thought out security policy which may require
+ revision and reimplementation. Understanding the different
security policy modules offered by the <acronym>MAC</acronym>
framework will help administrators choose the best policies
for their situations.</para>
- <para>The default &os; kernel does not include the option for
- the <acronym>MAC</acronym> framework; thus the following
- kernel option must be added before trying any of the examples or
- information in this chapter:</para>
-
- <programlisting>options MAC</programlisting>
-
- <para>And the kernel will require a rebuild and a
- reinstall.</para>
-
<caution>
- <para>While the various manual pages for <acronym>MAC</acronym>
- policy modules state that they may be built into the kernel,
- it is possible to lock the system out of
- the network and more. Implementing <acronym>MAC</acronym>
- is much like implementing a firewall, care must be taken
- to prevent being completely locked out of the system. The
- ability to revert back to a previous configuration should be
- considered while the implementation of <acronym>MAC</acronym>
- remotely should be done with extreme caution.</para>
+ <para>Implementing <acronym>MAC</acronym> is much like
+ implementing a firewall, care must be taken to prevent being
+ completely locked out of the system. The ability to revert
+ back to a previous configuration should be considered and the
+ implementation of <acronym>MAC</acronym> remotely should be
+ done with extreme caution.</para>
</caution>
</sect1>
@@ -383,65 +333,55 @@
which may be applied to subjects and objects throughout
the system.</para>
- <para>When setting a label, the user must be able to comprehend
- what it is, exactly, that is being done. The attributes
- available on an object depend on the policy module loaded, and
- that policy modules interpret their attributes in different
- ways. If improperly configured due to lack of comprehension,
- or the inability to understand the implications, the result
- will be the unexpected and perhaps, undesired, behavior of the
- system.</para>
+ <para>When setting a label, the administrator must be able to
+ comprehend what exactly is being done and understand any
+ implications in order to prevent unexpected or undesired
+ behavior of the system. The attributes available on an object
+ depend on the loaded policy module as policy modules interpret
+ their attributes in different ways.</para>
<para>The security label on an object is used as a part of a
security access control decision by a policy. With some
- policies, the label by itself contains all information necessary
- to make a decision; in other models, the labels may be processed
- as part of a larger rule set, etc.</para>
-
- <para>For instance, setting the label of
- <literal>biba/low</literal> on a file will represent a label
- maintained by the Biba security policy module, with a value
- of <quote>low</quote>.</para>
+ policies, the label contains all of the information necessary
+ to make a decision. In other policies, the labels may be
+ processed as part of a larger rule set. For instance, setting
+ the label of <literal>biba/low</literal> on a file will
+ represent a label maintained by the Biba security policy module,
+ with a value of <quote>low</quote>.</para>
<para>A few policy modules which support the labeling feature
- in &os; offer three specific predefined labels. These
- are the low, high, and equal labels. Although they enforce
- access control in a different manner with each policy module,
- you can be sure that the low label will be the lowest setting,
- the equal label will set the subject or object to be disabled
- or unaffected, and the high label will enforce the highest
- setting available in the Biba and <acronym>MLS</acronym>
+ in &os; offer three specific predefined labels: low, high, and
+ equal. Such policy modules enforce access control in a
+ different manner with each policy module, where the low label is
+ the lowest setting, the equal label sets the subject or object
+ to be disabled or unaffected, and the high label enforces the
+ highest setting available in the Biba and <acronym>MLS</acronym>
policy modules.</para>
<para>Within single label file system environments, only one
- label may be used on objects. This will enforce one set of
+ label may be used on objects. This label enforces one set of
access permissions across the entire system and in many
environments may be all that is required. There are a few
cases where multiple labels may be set on objects or subjects
- in the file system. For those cases, the
- <option>multilabel</option> option may be passed to
+ in the file system by passing <option>multilabel</option> to
&man.tunefs.8;.</para>
<para>In the case of Biba and <acronym>MLS</acronym>, a numeric
label may be set to indicate the precise level of hierarchical
control. This numeric level is used to partition or sort
- information into different groups of say, classification only
+ information into different groups of classification only
permitting access to that group or a higher group level.</para>
- <para>In most cases the administrator will only be setting up a
- single label to use throughout the file system.</para>
-
- <para><emphasis>Hey wait, this is similar to
- <acronym>DAC</acronym>! I thought <acronym>MAC</acronym> gave
- control strictly to the administrator.</emphasis> That
- statement still holds true, to some extent as
+ <para>In most cases, the administrator will set up a single label
+ to use throughout the file system. This is similar to
+ <acronym>DAC</acronym> to some extent as
<username>root</username> is the one in control and who
configures the policies so that users are placed in the
appropriate categories/access levels. Alas, many policy modules
can restrict the <username>root</username> user as well. Basic
control over objects will then be released to the group, but
<username>root</username> may revoke or modify the settings
- at any time. This is the hierarchal/clearance model covered
+ at any time. This is the hierarchical/clearance model covered
by policies such as Biba and <acronym>MLS</acronym>.</para>
<sect2>
@@ -453,29 +393,26 @@
configuration or the manipulation and verification of
the configuration.</para>
- <para>All configuration may be done by use of the
- &man.setfmac.8; and &man.setpmac.8; utilities.
- The <command>setfmac</command> command is used to set
- <acronym>MAC</acronym> labels on system objects while the
- <command>setpmac</command> command is used to set the labels
- on system subjects. Observe:</para>
+ <para>All configuration may be done using &man.setfmac.8; and
+ &man.setpmac.8;. <command>setfmac</command> is used to set
+ <acronym>MAC</acronym> labels on system objects while
+ <command>setpmac</command> is used to set the labels on system
+ subjects. Observe:</para>
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
- <para>If no errors occurred with the command above, a prompt
- will be returned. The only time these commands are not
- quiescent is when an error occurred; similarly to the
- &man.chmod.1; and &man.chown.8; commands. In some cases this
- error may be a <errorname>Permission denied</errorname> and
- is usually obtained when the label is being set or modified
- on an object which is restricted.<footnote><para>Other conditions
- may produce different failures. For instance, the file may
- not be owned by the user attempting to relabel the object,
- the object may not exist or may be read only. A mandatory
- policy will not allow the process to relabel the file, maybe
+ <para>If the configuration is successful, the prompt will be
+ returned without error. A common error is
+ <errorname>Permission denied</errorname> which usually occurs
+ when the label is being set or modified on an object which is
+ restricted.<footnote><para>Other conditions may produce different
+ failures. For instance, the file may not be owned by the
+ user attempting to relabel the object, the object may not
+ exist, or the object may be read only. A mandatory policy
+ will not allow the process to relabel the file, maybe
because of a property of the file, a property of the
process, or a property of the proposed new label value. For
- example: a user running at low integrity tries to change the
+ example, a user running at low integrity tries to change the
label of a high integrity file. Or perhaps a user running
at low integrity tries to change the label of a low
integrity file to a high integrity label.</para></footnote> The
@@ -488,18 +425,16 @@
&prompt.root; <userinput>getfmac test</userinput>
test: biba/high</screen>
- <para>As we see above, <command>setpmac</command>
- can be used to override the policy module's settings by
- assigning a different label to the invoked process. The
- <command>getpmac</command> utility is usually used with
- currently running processes, such as
- <application>sendmail</application>: although it takes a
- process ID in place of a command the logic is extremely
- similar. If users attempt to manipulate a file not in their
- access, subject to the rules of the loaded policy modules,
- the <errorname>Operation not permitted</errorname> error
- will be displayed by the <function>mac_set_link</function>
- function.</para>
+ <para><command>setpmac</command> can be used to override the
+ policy module's settings by assigning a different label to the
+ invoked process. <command>getpmac</command> is usually used
+ with currently running processes, such as
+ <application>sendmail</application>. It takes a process ID in
+ place of a command. If users attempt to manipulate a file not
+ in their access, subject to the rules of the loaded policy
+ modules, the <errorname>Operation not permitted</errorname>
+ error will be displayed by the
+ <function>mac_set_link</function> function.</para>
<sect3>
<title>Common Label Types</title>
@@ -507,15 +442,14 @@ test: biba/high</screen>
<para>For the &man.mac.biba.4;, &man.mac.mls.4; and
&man.mac.lomac.4; policy modules, the ability to assign
simple labels is provided. These take the form of high,
- equal and low, what follows is a brief description of
- what these labels provide:</para>
+ equal, and low, where:</para>
<itemizedlist>
<listitem>
<para>The <literal>low</literal> label is considered the
lowest label setting an object or subject may have.
- Setting this on objects or subjects will block their
- access to objects or subjects marked high.</para>
+ Setting this on objects or subjects blocks their access
+ to objects or subjects marked high.</para>
</listitem>
<listitem>
@@ -531,66 +465,62 @@ test: biba/high</screen>
</itemizedlist>
<para>With respect to each policy module, each of those
- settings will instate a different information flow
- directive. Reading the proper manual pages will further
- explain the traits of these generic label
+ settings will establish a different information flow
+ directive. Refer to the manual pages of the module to
+ determine the traits of these generic label
configurations.</para>
<sect4>
<title>Advanced Label Configuration</title>
<para>Numeric grade labels are used for
- <literal>comparison:compartment+compartment</literal>;
- thus the following:</para>
+ <literal>comparison:compartment+compartment</literal>.
+ For example:</para>
<programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting>
- <para>May be interpreted as:</para>
-
- <para><quote>Biba Policy Label</quote>/<quote>Grade
+ <para>may be interpreted as <quote>Biba Policy
+ Label</quote>/<quote>Grade
10</quote>:<quote>Compartments 2, 3 and 6</quote>:
(<quote>grade 5 ...</quote>)</para>
<para>In this example, the first grade would be considered
the <quote>effective grade</quote> with
<quote>effective compartments</quote>, the second grade
- is the low grade and the last one is the high grade.
- In most configurations these settings will not be used;
- indeed, they offered for more advanced
- configurations.</para>
+ is the low grade, and the last one is the high grade.
+ In most configurations, these settings will not be used
+ as they are advanced configurations.</para>
- <para>When applied to system objects, they will only have a
- current grade/compartments as opposed to system subjects
- as they reflect the range of available rights in the
- system, and network interfaces, where they are used for
- access control.</para>
+ <para>System objects only have a current grade/compartment.
+ System subjects reflect the range of available rights in
+ the system, and network interfaces, where they are used
+ for access control.</para>
<para>The grade and compartments in a subject and object
- pair are used to construct a relationship referred to as
+ pair are used to construct a relationship known as
<quote>dominance</quote>, in which a subject dominates an
object, the object dominates the subject, neither
dominates the other, or both dominate each other. The
<quote>both dominate</quote> case occurs when the two
labels are equal. Due to the information flow nature of
- Biba, you have rights to a set of compartments,
- <quote>need to know</quote>, that might correspond to
- projects, but objects also have a set of compartments.
- Users may have to subset their rights using
- <command>su</command> or <command>setpmac</command> in
- order to access objects in a compartment from which they
- are not restricted.</para>
+ Biba, a user has rights to a set of compartments that
+ might correspond to projects, but objects also have a set
+ of compartments. Users may have to subset their rights
+ using <command>su</command> or <command>setpmac</command>
+ in order to access objects in a compartment from which
+ they are not restricted.</para>
</sect4>
</sect3>
<sect3>
<title>Users and Label Settings</title>
- <para>Users themselves are required to have labels so that
- their files and processes may properly interact with the
- security policy defined on the system. This is
- configured through the <filename>login.conf</filename> file
- by use of login classes. Every policy module that uses
- labels will implement the user class setting.</para>
+ <para>Users are required to have labels so that their files
+ and processes properly interact with the security policy
+ defined on the system. This is configured in
+ <filename>login.conf</filename> using login classes. Every
+ policy module that uses labels will implement the user class
+ setting.</para>
<para>An example entry containing every policy module setting
is displayed below:</para>
@@ -619,49 +549,49 @@ test: biba/high</screen>
:ignoretime@:\
:label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:</programlisting>
- <para>The <literal>label</literal> option is used to set the
+ <para>To set the
user class default label which will be enforced by
- <acronym>MAC</acronym>. Users will never be permitted to
- modify this value, thus it can be considered not optional
- in the user case. In a real configuration, however, the
- administrator will never wish to enable every policy module.
- It is recommended that the rest of this chapter be reviewed
- before any of this configuration is implemented.</para>
+ <acronym>MAC</acronym>, use <option>label</option>. Users
+ are never permitted to modify this value. In a real
+ configuration, however, the administrator would never enable
+ every policy module. It is recommended that the rest of
+ this chapter be reviewed before any configuration is
+ implemented.</para>
<note>
- <para>Users may change their label after the initial login;
- however, this change is subject constraints of the policy.
- The example above tells the Biba policy that a process's
- minimum integrity is 5, its maximum is 15, but the default
- effective label is 10. The process will run at 10 until
- it chooses to change label, perhaps due to the user using
- the setpmac command, which will be constrained by Biba to
- the range set at login.</para>
+ <para>Users may change their label after they login, subject
+ to the constraints of the policy. The example above tells
+ the Biba policy that a process's minimum integrity is 5,
+ its maximum is 15, and the default effective label is 10.
+ The process will run at 10 until it chooses to change
+ label, perhaps due to the user using &man.setpmac.8;,
+ which will be constrained by Biba to the configured
+ range.</para>
</note>
- <para>In all cases, after a change to
+ <para>After any change to
<filename>login.conf</filename>, the login class capability
- database must be rebuilt using <command>cap_mkdb</command>
- and this will be reflected throughout every forthcoming
- example or discussion.</para>
-
- <para>It is useful to note that many sites may have a
- particularly large number of users requiring several
- different user classes. In depth planning is required
- as this may get extremely difficult to manage.</para>
+ database must be rebuilt using
+ <command>cap_mkdb</command>.</para>
+
+ <para>Many sites have a large number of users requiring
+ several different user classes. In depth planning is
+ required as this may get extremely difficult to
+ manage.</para>
</sect3>
<sect3>
<title>Network Interfaces and Label Settings</title>
- <para>Labels may also be set on network interfaces to help
- control the flow of data across the network. In all cases
- they function in the same way the policies function with
- respect to objects. Users at high settings in
- <literal>biba</literal>, for example, will not be permitted
- to access network interfaces with a label of low.</para>
+ <para>Labels may be set on network interfaces to help
+ control the flow of data across the network. Policies
+ using network interface labels function in the same way that
+ policies function with respect to objects. Users at high
+ settings in <literal>biba</literal>, for example, will not
+ be permitted to access network interfaces with a label of
+ low.</para>
- <para>The <option>maclabel</option> may be passed to
+ <para><option>maclabel</option> may be passed to
<command>ifconfig</command> when setting the
<acronym>MAC</acronym> label on network interfaces. For
example:</para>
@@ -671,51 +601,44 @@ test: biba/high</screen>
<para>will set the <acronym>MAC</acronym> label of
<literal>biba/equal</literal> on the &man.bge.4; interface.
When using a setting similar to
- <literal>biba/high(low-high)</literal> the entire label
- should be quoted; otherwise an error will be
+ <literal>biba/high(low-high)</literal>, the entire label
+ should be quoted to prevent an error from being
returned.</para>
<para>Each policy module which supports labeling has a tunable
which may be used to disable the <acronym>MAC</acronym>
label on network interfaces. Setting the label to
<option>equal</option> will have a similar effect. Review
- the output from <command>sysctl</command>, the policy manual
- pages, or even the information found later in this chapter
- for those tunables.</para>
+ the output of <command>sysctl</command>, the policy manual
+ pages, and the information in this chapter for more
+ information on those tunables.</para>
</sect3>
</sect2>
<sect2>
<title>Singlelabel or Multilabel?</title>
- <para>By default the system will use the
- <option>singlelabel</option> option. But what does this
- mean to the administrator? There are several differences
- which, in their own right, offer pros and cons to the
- flexibility in the systems security model.</para>
-
- <para>The <option>singlelabel</option> only permits for one
- label, for instance <literal>biba/high</literal> to be used
- for each subject or object. It provides for lower
- administration overhead but decreases the flexibility of
- policies which support labeling. Many administrators may
- want to use the <option>multilabel</option> option in
- their security policy.</para>
-
- <para>The <option>multilabel</option> option will permit each
- subject or object to have its own independent
- <acronym>MAC</acronym> label in
- place of the standard <option>singlelabel</option> option
- which will allow only one label throughout the partition.
- The <option>multilabel</option> and <option>single</option>
- label options are only required for the policies which
- implement the labeling feature, including the Biba, Lomac,
- <acronym>MLS</acronym> and <acronym>SEBSD</acronym>
- policies.</para>
+ <para>By default, the system will use
+ <option>singlelabel</option>. For the administrator, there
+ are several differences which offer pros and cons to the
+ flexibility in the system's security model.</para>
- <para>In many cases, the <option>multilabel</option> may not
- need to be set at all. Consider the following situation and
- security model:</para>
+ <para>A security policy which uses <option>singlelabel</option>
+ only permits one label, such as <literal>biba/high</literal>,
+ to be used for each subject or object. This provides lower
+ administration overhead, but decreases the flexibility of
+ policies which support labeling.</para>
+
+ <para><option>multilabel</option> permits each subject or object
+ to have its own independent <acronym>MAC</acronym> label.
+ The decision to use <option>multilabel</option> or
+ <option>singlelabel</option> is only required for the policies
+ which implement the labeling feature, including the Biba,
+ Lomac, and <acronym>MLS</acronym> policies.</para>
+
+ <para>In many cases, <option>multilabel</option> may not be
+ needed. Consider the following situation and security
+ model:</para>
<itemizedlist>
<listitem>
@@ -726,49 +649,41 @@ test: biba/high</screen>
<listitem>
<para>This machine only requires one label,
<literal>biba/high</literal>, for everything in the
- system. Here the file system would not require the
- <option>multilabel</option> option as a single label
- will always be in effect.</para>
+ system. This file system would not require
+ <option>multilabel</option> as a single label will always
+ be in effect.</para>
</listitem>
<listitem>
<para>But, this machine will be a web server and should
have the web server run at <literal>biba/low</literal>
- to prevent write up capabilities. The Biba policy and
- how it works will be discussed later, so if the previous
- comment was difficult to interpret just continue reading
- and return. The server could use a separate partition
- set at <literal>biba/low</literal> for most if not all
- of its runtime state. Much is lacking from this example,
- for instance the restrictions on data, configuration and
- user settings; however, this is just a quick example to
- prove the aforementioned point.</para>
+ to prevent write up capabilities. The server could
+ use a separate partition set at
+ <literal>biba/low</literal> for most if not all
+ of its runtime state.</para>
</listitem>
</itemizedlist>
<para>If any of the non-labeling policies are to be used,
- then the <option>multilabel</option> option would never
- be required. These include the
- <literal>seeotheruids</literal>, <literal>portacl</literal>
- and <literal>partition</literal> policies.</para>
-
- <para>It should also be noted that using
- <option>multilabel</option> with a partition and establishing
- a security model based on <option>multilabel</option>
- functionality could open the doors for higher administrative
- overhead as everything in the file system would have a label.
- This includes directories, files, and even device
+ <option>multilabel</option> would not be required. These
+ include the <literal>seeotheruids</literal>,
+ <literal>portacl</literal> and <literal>partition</literal>
+ policies.</para>
+
+ <para>Using <option>multilabel</option> with a partition and
+ establishing a security model based on
+ <option>multilabel</option> functionality could increase
+ administrative overhead as everything in the file system has a
+ label. This includes directories, files, and even device
nodes.</para>
<para>The following command will set <option>multilabel</option>
on the file systems to have multiple labels. This may only be
- done in single user mode:</para>
+ done in single user mode and is not a requirement for the swap
+ file system:</para>
<screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen>
- <para>This is not a requirement for the swap file
- system.</para>
-
<note>
<para>Some users have experienced problems with setting the
<option>multilabel</option> flag on the root partition.
@@ -782,20 +697,9 @@ test: biba/high</screen>
<title>Planning the Security Configuration</title>
<para>Whenever a new technology is implemented, a planning phase
- is always a good idea. During the planning stages, an
- administrator should in general look at the <quote>big
- picture</quote>, trying to keep in view at least the
- following:</para>
-
- <itemizedlist>
- <listitem>
- <para>The implementation requirements;</para>
- </listitem>
-
- <listitem>
- <para>The implementation goals;</para>
- </listitem>
- </itemizedlist>
+ 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>
@@ -807,8 +711,8 @@ test: biba/high</screen>
</listitem>
<listitem>
- <para>What sorts of information or resources to restrict
- access to along with the type of restrictions that should be
+ <para>Which information or resources to restrict access to
+ along with the type of restrictions that should be
applied.</para>
</listitem>
@@ -818,60 +722,54 @@ test: biba/high</screen>
</listitem>
</itemizedlist>
- <para>It is always possible to reconfigure and change the
- system resources and security settings, it is quite often very
- inconvenient to search through the system and fix existing
- files and user accounts. Planning helps to ensure a
- trouble-free and efficient trusted system implementation. A
- trial run of the trusted system, including the configuration,
- is often vital and definitely beneficial
+ <para>Good planning helps to ensure a trouble-free and efficient
+ trusted system implementation. A trial run of the trusted
+ system and its configuration should occur
<emphasis>before</emphasis> a <acronym>MAC</acronym>
implementation is used on production systems. The idea of
just letting loose on a system with <acronym>MAC</acronym> is
like setting up for failure.</para>
- <para>Different environments may have explicit needs and
+ <para>Different environments have different needs and
requirements. Establishing an in depth and complete security
profile will decrease the need of changes once the system
- goes live. As such, the future sections will cover the
- different modules available to administrators; describe their
- use and configuration; and in some cases provide insight on
- what situations they would be most suitable for. For instance,
- a web server might roll out the &man.mac.biba.4; and
- &man.mac.bsdextended.4; policies. In other cases, a machine
- with very few local users, the &man.mac.partition.4; might
- be a good choice.</para>
+ goes live. The rest of this chapter covers the available
+ modules, describes their use and configuration, and in some
+ cases, provides insight on applicable situations. For instance,
+ a web server might use the &man.mac.biba.4; and
+ &man.mac.bsdextended.4; policies. In the case of a machine
+ with few local users, &man.mac.partition.4; might be a good
+ choice.</para>
</sect1>
<sect1 id="mac-modules">
<title>Module Configuration</title>
- <para>Every module included with the <acronym>MAC</acronym>
- framework may be either compiled into the kernel as noted above
- or loaded as a run-time kernel module.
- The recommended method is to add the module name to the
- <filename>/boot/loader.conf</filename> file so that it will load
- during the initial boot operation.</para>
-
- <para>The following sections will discuss the various
- <acronym>MAC</acronym> modules and cover their features.
- Implementing them into a specific environment will also
- be a consideration of this chapter. 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 would enforce only one label
+ <para>Beginning with &os;&nbsp;8.0, the default &os; kernel
+ includes <literal>options MAC</literal>. This means that
+ every module included with the <acronym>MAC</acronym>
+ framework may be loaded as a run-time kernel module. The
+ recommended method is to add the module name to
+ <filename>/boot/loader.conf</filename> so that it will load
+ during boot. Each module also provides a kernel option
+ for those administrators who choose to compile their own
+ custom kernel.</para>
+
+ <para>Some modules support the use of labeling, which is
+ controlling access by enforcing a label such as <quote>this is
+ allowed and this is not</quote>. A label configuration file may
+ control how files may be accessed, network communication can be
+ exchanged, and more. The previous section showed how the
+ <option>multilabel</option> flag could be set on file systems to
+ enable per-file or per-partition access control.</para>
+
+ <para>A single label configuration enforces only one label
across the system, that is why the <command>tunefs</command>
option is called <option>multilabel</option>.</para>
</sect1>
<sect1 id="mac-seeotheruids">
- <title>The MAC seeotheruids Module</title>
+ <title>The &man.mac.seeotheruids.4; Module</title>
<indexterm>
<primary>MAC See Other UIDs Policy</primary>
@@ -885,8 +783,8 @@ test: biba/high</screen>
<literal>mac_seeotheruids_load="YES"</literal></para>
<para>The &man.mac.seeotheruids.4; module mimics and extends
- the <literal>security.bsd.see_other_uids</literal> and
- <literal>security.bsd.see_other_gids</literal>
+ 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>
@@ -897,37 +795,36 @@ test: biba/high</screen>
<itemizedlist>
<listitem>
- <para><literal>security.mac.seeotheruids.enabled</literal>
- will enable the module's features and use the default
- settings. These default settings will deny users the
- ability to view processes and sockets owned by other
- users.</para>
+ <para><varname>security.mac.seeotheruids.enabled</varname>
+ enables the module and uses the default settings which deny
+ users the ability to view processes and sockets owned by
+ other users.</para>
</listitem>
<listitem>
<para>
- <literal>security.mac.seeotheruids.specificgid_enabled</literal>
- will allow a certain group to be exempt from this policy.
- To exempt specific groups from this policy, use the
- <literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal>
- <command>sysctl</command> tunable. In the above example,
- the <replaceable>XXX</replaceable> should be replaced with
- the numeric group ID to be exempted.</para>
+ <varname>security.mac.seeotheruids.specificgid_enabled</varname>
+ allows certain groups to be exempt from this policy. To
+ exempt specific groups from this policy, use the
+ <varname>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></varname>
+ <command>sysctl</command> tunable. Replace
+ <replaceable>XXX</replaceable> with the numeric group ID to
+ be exempted.</para>
</listitem>
<listitem>
<para>
- <literal>security.mac.seeotheruids.primarygroup_enabled</literal>
+ <varname>security.mac.seeotheruids.primarygroup_enabled</varname>
is used to exempt specific primary groups from this policy.
- When using this tunable, the
- <literal>security.mac.seeotheruids.specificgid_enabled</literal>
+ When using this tunable,
+ <varname>security.mac.seeotheruids.specificgid_enabled</varname>
may not be set.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="mac-bsdextended">
- <title>The MAC bsdextended Module</title>
+ <title>The &man.mac.bsdextended.4; Module</title>
<indexterm>
<primary>MAC</primary>
@@ -950,18 +847,17 @@ test: biba/high</screen>
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,
- security.mac.bsdextended.firstmatch_enabled. Similar to
- other firewall modules in &os;, a file containing access
- control rules can be created and read by the system at boot
- time using an &man.rc.conf.5; variable.</para>
+ <varname>security.mac.bsdextended.firstmatch_enabled</varname>.
+ Similar to other firewall modules in &os;, a file containing
+ the access control rules can be created and read by the system
+ at boot time using an &man.rc.conf.5; variable.</para>
- <para>The rule list may be entered using a utility,
- &man.ugidfw.8;, that has a syntax similar to that of
- &man.ipfw.8;. More tools can be written by using the functions
- in the &man.libugidfw.3; library.</para>
+ <para>The rule list may be entered using &man.ugidfw.8; which has
+ a syntax similar to &man.ipfw.8;. More tools can be written by
+ using the functions in the &man.libugidfw.3; library.</para>
<para>Extreme caution should be taken when working with this
- module; incorrect use could block access to certain parts of
+ module as incorrect use could block access to certain parts of
the file system.</para>
<sect2>
@@ -974,48 +870,41 @@ test: biba/high</screen>
<screen>&prompt.root; <userinput>ugidfw list</userinput>
0 slots, 0 rules</screen>
- <para>As expected, there are no rules defined. This means that
- everything is still completely accessible. To create a rule
- which will block all access by users but leave
- <username>root</username> unaffected, simply run the
- following command:</para>
+ <para>By default, no rules are defined and everything is
+ completely accessible. To create a rule which will block all
+ access by users but leave <username>root</username>
+ unaffected, run the following command:</para>
<screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen>
<para>This is a very bad idea as it will block all users from
issuing even the most simple commands, such as
- <command>ls</command>. A more patriotic list of rules
- might be:</para>
+ <command>ls</command>. The next example will block
+ <username>user1</username> any and all access, including
+ directory listings, to
+ <username><replaceable>user2</replaceable></username>'s home
+ directory:</para>
<screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput>
&prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen>
- <para>This will block any and all access, including directory
- listings, to
- <username><replaceable>user2</replaceable></username>'s home
- directory from the username <username>user1</username>.</para>
-
- <para>In place of <username>user1</username>, the
+ <para>Instead of <username>user1</username>,
<option>not uid <replaceable>user2</replaceable></option>
- could be passed. This will enforce the same access
- restrictions above for all users in place of just one
- user.</para>
+ could be used. This enforces the same access restrictions for
+ all users instead of just one user.</para>
<note>
- <para>The <username>root</username> user will be unaffected
- by these changes.</para>
+ <para>The <username>root</username> user is unaffected by
+ these changes.</para>
</note>
- <para>This should provide a general idea of how the
- &man.mac.bsdextended.4; module may be used to help fortify
- a file system. For more information, see the
- &man.mac.bsdextended.4; and the &man.ugidfw.8; manual
- pages.</para>
+ <para>For more information, refer to &man.mac.bsdextended.4; and
+ &man.ugidfw.8;</para>
</sect2>
</sect1>
<sect1 id="mac-ifoff">
- <title>The MAC ifoff Module</title>
+ <title>The &man.mac.ifoff.4; Module</title>
<indexterm>
<primary>MAC Interface Silencing Policy</primary>
@@ -1025,33 +914,34 @@ test: biba/high</screen>
<para>Kernel configuration line:
<literal>options MAC_IFOFF</literal></para>
- <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para>
+ <para>Boot option:
+ <literal>mac_ifoff_load="YES"</literal></para>
<para>The &man.mac.ifoff.4; module exists solely to disable
network interfaces on the fly and keep network interfaces from
- being brought up during the initial system boot. It does not
- require any labels to be set up on the system, nor does it have
- a dependency on other <acronym>MAC</acronym> modules.</para>
+ being brought up during system boot. It does not require any
+ labels to be set up on the system, nor does it depend on other
+ <acronym>MAC</acronym> modules.</para>
- <para>Most of the control is done through the
+ <para>Most of this module's control is performed through the
<command>sysctl</command> tunables listed below.</para>
<itemizedlist>
<listitem>
- <para><literal>security.mac.ifoff.lo_enabled</literal> will
- enable/disable all traffic on the loopback (&man.lo.4;)
+ <para><varname>security.mac.ifoff.lo_enabled</varname>
+ enables or disables all traffic on the loopback (&man.lo.4;)
interface.</para>
</listitem>
<listitem>
- <para><literal>security.mac.ifoff.bpfrecv_enabled</literal>
- will enable/disable all traffic on the Berkeley Packet
+ <para><varname>security.mac.ifoff.bpfrecv_enabled</varname>
+ enables or disables all traffic on the Berkeley Packet
Filter interface (&man.bpf.4;)</para>
</listitem>
<listitem>
- <para><literal>security.mac.ifoff.other_enabled</literal> will
- enable/disable traffic on all other interfaces.</para>
+ <para><varname>security.mac.ifoff.other_enabled</varname>
+ enables or disables traffic on all other interfaces.</para>
</listitem>
</itemizedlist>
@@ -1065,7 +955,7 @@ test: biba/high</screen>
</sect1>
<sect1 id="mac-portacl">
- <title>The MAC portacl Module</title>
+ <title>The &man.mac.portacl.4; Module</title>
<indexterm>
<primary>MAC Port Access Control List Policy</primary>
@@ -1080,119 +970,106 @@ test: biba/high</screen>
<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. In
- essence &man.mac.portacl.4; makes it possible to allow
+ using a variety of <command>sysctl</command> variables.
+ &man.mac.portacl.4; makes it possible to allow
non-<username>root</username> users to bind to specified
- privileged ports, i.e., ports below 1024.</para>
+ privileged ports below 1024.</para>
- <para>Once loaded, this module will enable the
+ <para>Once loaded, this module enables the
<acronym>MAC</acronym> policy on all sockets. The following
tunables are available:</para>
<itemizedlist>
<listitem>
- <para><literal>security.mac.portacl.enabled</literal> will
- enable/disable the policy completely.</para>
+ <para><varname>security.mac.portacl.enabled</varname>
+ enables or disables the policy completely.</para>
</listitem>
<listitem>
- <para><literal>security.mac.portacl.port_high</literal> will
- set the highest port number that &man.mac.portacl.4;
- will enable protection for.</para>
+ <para><varname>security.mac.portacl.port_high</varname>
+ sets the highest port number that &man.mac.portacl.4;
+ protects.</para>
</listitem>
<listitem>
- <para><literal>security.mac.portacl.suser_exempt</literal>
- will, when set to a non-zero value, exempt the
+ <para><varname>security.mac.portacl.suser_exempt</varname>,
+ when set to a non-zero value, exempts the
<username>root</username> user from this policy.</para>
</listitem>
<listitem>
- <para><literal>security.mac.portacl.rules</literal> will
- specify the actual mac_portacl policy; see below.</para>
+ <para><varname>security.mac.portacl.rules</varname>
+ specifies the mac_portacl policy, which is a text string of
+ the form: <literal>rule[,rule,...]</literal> with as many
+ rules as needed. Each rule is of the form:
+ <literal>idtype:id:protocol:port</literal>. The
+ <parameter>idtype</parameter> parameter can be
+ <literal>uid</literal> or <literal>gid</literal> and is used
+ to interpret the <parameter>id</parameter> parameter as
+ either a user id or group id, respectively. The
+ <parameter>protocol</parameter> parameter is used to
+ determine if the rule should apply to <acronym>TCP</acronym>
+ or <acronym>UDP</acronym> by setting the parameter to
+ <literal>tcp</literal> or <literal>udp</literal>. The final
+ <parameter>port</parameter> parameter is the port number to
+ allow the specified user or group to bind to.</para>
</listitem>
</itemizedlist>
- <para>The actual <literal>mac_portacl</literal> policy, as
- specified in the <literal>security.mac.portacl.rules</literal>
- sysctl, is a text string of the form:
- <literal>rule[,rule,...]</literal> with as many rules as
- needed. Each rule is of the form:
- <literal>idtype:id:protocol:port</literal>. The
- <parameter>idtype</parameter> parameter can be
- <literal>uid</literal> or <literal>gid</literal> and used to
- interpret the <parameter>id</parameter> parameter as either a
- user id or group id, respectively. The
- <parameter>protocol</parameter> parameter is used to determine
- if the rule should apply to <acronym>TCP</acronym> or
- <acronym>UDP</acronym> by setting the parameter to
- <literal>tcp</literal> or <literal>udp</literal>. The final
- <parameter>port</parameter> parameter is the port number to
- allow the specified user or group to bind to.</para>
-
<note>
- <para>Since the ruleset is interpreted directly by the kernel
+ <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>
+ and port parameters. Names cannot be used for users,
+ groups, or services.</para>
</note>
- <para>By default, on &unix;-like systems, ports below 1024
- can only be used by/bound to privileged processes,
- i.e., those run as <username>root</username>. For
- &man.mac.portacl.4; to allow non-privileged processes to bind
- to ports below 1024 this standard &unix; restriction has to
- be disabled. This can be accomplished by setting the
- &man.sysctl.8; variables
- <literal>net.inet.ip.portrange.reservedlow</literal> and
- <literal>net.inet.ip.portrange.reservedhigh</literal>
- to zero.</para>
+ <para>By default, ports below 1024 can only be used by or bound
+ to privileged processes, which run as
+ <username>root</username>. For &man.mac.portacl.4; to allow
+ non-privileged processes to bind to ports below 1024, this
+ restriction has to be disabled by setting the &man.sysctl.8;
+ variables
+ <varname>net.inet.ip.portrange.reservedlow</varname> and
+ <varname>net.inet.ip.portrange.reservedhigh</varname> to
+ zero:</para>
+
+ <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
+&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0
+net.inet.ip.portrange.reservedhigh=0</userinput></screen>
- <para>See the examples below or review the &man.mac.portacl.4;
- manual page for further information.</para>
+ <para>See the examples below or refer to &man.mac.portacl.4; for
+ further information.</para>
<sect2>
<title>Examples</title>
- <para>The following examples should illuminate the above
- discussion a little better:</para>
-
- <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
-&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0</userinput></screen>
-
- <para>First we set &man.mac.portacl.4; to cover the standard
- privileged ports and disable the normal &unix; bind
- restrictions.</para>
+ <para>Since the <username>root</username> user should not be
+ crippled by this policy, this example starts by setting the
+ <varname>security.mac.portacl.suser_exempt</varname> to a
+ non-zero value.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen>
- <para>The <username>root</username> user should not be crippled
- by this policy, thus set the
- <literal>security.mac.portacl.suser_exempt</literal> to a
- non-zero value. The &man.mac.portacl.4; module
- has now been set up to behave the same way &unix;-like systems
- behave by default.</para>
+ <para>Next, allow the user with <acronym>UID</acronym> 80
+ to bind to port 80. This allows the <username>www</username>
+ user to run a web server without ever having
+ <username>root</username> privilege.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen>
- <para>Allow the user with <acronym>UID</acronym> 80 (normally
- the <username>www</username> user) to bind to port 80.
- This can be used to allow the <username>www</username>
- user to run a web server without ever having
- <username>root</username> privilege.</para>
+ <para>The next example permits the user with the
+ <acronym>UID</acronym> of 1001 to bind to the
+ <acronym>TCP</acronym> ports 110 (<quote>pop3</quote>) and 995
+ (<quote>pop3s</quote>). This permits this user to start a
+ server that accepts connections on ports 110 and 995.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
- <para>Permit 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 will permit this user to start a server that accepts
- connections on ports 110 and 995.</para>
</sect2>
</sect1>
<sect1 id="mac-partition">
- <title>The MAC partition Module</title>
+ <title>The &man.mac.partition.4; Module</title>
<indexterm>
<primary>MAC Process Partition Policy</primary>
@@ -1207,23 +1084,18 @@ test: biba/high</screen>
<para>The &man.mac.partition.4; policy will drop processes into
specific <quote>partitions</quote> based on their
- <acronym>MAC</acronym> label. Think of it as a special
- type of &man.jail.8;, though that is hardly a worthy
- comparison.</para>
-
- <para>This is one module that should be added to the
- &man.loader.conf.5; file so that it loads
- and enables the policy during the boot process.</para>
+ <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
- the &man.setpmac.8; utility which will be explained below.
- The following <command>sysctl</command> tunable is
+ &man.setpmac.8;. One <command>sysctl</command> tunable is
available for this policy:</para>
<itemizedlist>
<listitem>
- <para><literal>security.mac.partition.enabled</literal> will
- enable the enforcement of <acronym>MAC</acronym> process
+ <para><varname>security.mac.partition.enabled</varname>
+ enables the enforcement of <acronym>MAC</acronym> process
partitions.</para>
</listitem>
</itemizedlist>
@@ -1232,32 +1104,30 @@ test: biba/high</screen>
to see their processes, and any others within their partition,
but will not be permitted to work with utilities outside the
scope of this partition. For instance, a user in the
- <literal>insecure</literal> class above will not be permitted
- to access the <command>top</command> command as well as many
- other commands that must spawn a process.</para>
+ <literal>insecure</literal> class will not be permitted to
+ access <command>top</command> as well as many other commands
+ that must spawn a process.</para>
<para>To set or drop utilities into a partition label, use the
<command>setpmac</command> utility:</para>
<screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
- <para>This will add the <command>top</command> command to the
- label set on users in the <literal>insecure</literal> class.
- Note that all processes spawned by users
- in the <literal>insecure</literal> class will stay in the
- <literal>partition/13</literal> label.</para>
+ <para>This example adds <command>top</command> to the label set on
+ users in the <literal>insecure</literal> class. All processes
+ spawned by users in the <literal>insecure</literal> class will
+ stay in the <literal>partition/13</literal> label.</para>
<sect2>
<title>Examples</title>
- <para>The following command will show you the partition label
+ <para>The following command will display the partition label
and the process list:</para>
<screen>&prompt.root; <userinput>ps Zax</userinput></screen>
- <para>This next command will allow the viewing of another
- user's process partition label and that user's currently
- running processes:</para>
+ <para>This command will display another user's process partition
+ label and that user's currently running processes:</para>
<screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen>
@@ -1299,13 +1169,13 @@ test: biba/high</screen>
flow policy.</para>
<para>In <acronym>MLS</acronym> environments, a
- <quote>clearance</quote> level is set in each subject or objects
- label, along with compartments. Since these clearance or
- sensibility levels can reach numbers greater than six 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 already included in this
- policy.</para>
+ <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>.
@@ -1318,9 +1188,9 @@ test: biba/high</screen>
configuration which permits it to be dominated by all other
objects. Anything labeled with <literal>mls/low</literal>
will have a low clearance level and not be permitted to
- access information of a higher level. In addition, this
- label will prevent objects of a higher clearance level from
- writing or passing information on to them.</para>
+ access information of a higher level. This label also
+ prevents objects of a higher clearance level from writing or
+ passing information on to them.</para>
</listitem>
<listitem>
@@ -1338,30 +1208,31 @@ test: biba/high</screen>
</listitem>
</itemizedlist>
- <para><acronym>MLS</acronym> provides for:</para>
+ <para><acronym>MLS</acronym> provides:</para>
<itemizedlist>
<listitem>
<para>A hierarchical security level with a set of non
- hierarchical categories;</para>
+ hierarchical categories.</para>
</listitem>
<listitem>
- <para>Fixed rules: no read up, no write down (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>
+ <para>Fixed rules of <literal>no read up, no write
+ down</literal>. This means that a subject can have read
+ access to objects on its own level or below, but not above.
+ Similarly, a subject can have write access to objects on its
+ own level or above but not beneath.</para>
</listitem>
<listitem>
- <para>Secrecy (preventing inappropriate disclosure
- of data);</para>
+ <para>Secrecy, or the prevention of inappropriate disclosure
+ of data.</para>
</listitem>
<listitem>
- <para>Basis for the design of systems that concurrently handle
- data at multiple sensitivity levels (without leaking
- information between secret and confidential).</para>
+ <para>A basis for the design of systems that concurrently
+ handle data at multiple sensitivity levels without leaking
+ information between secret and confidential.</para>
</listitem>
</itemizedlist>
@@ -1371,77 +1242,71 @@ test: biba/high</screen>
<itemizedlist>
<listitem>
- <para><literal>security.mac.mls.enabled</literal> is used to
- enable/disable the <acronym>MLS</acronym> policy.</para>
+ <para><varname>security.mac.mls.enabled</varname> is used to
+ enable or disable the <acronym>MLS</acronym> policy.</para>
</listitem>
<listitem>
- <para><literal>security.mac.mls.ptys_equal</literal> will
- label all &man.pty.4; devices as
+ <para><varname>security.mac.mls.ptys_equal</varname>
+ labels all &man.pty.4; devices as
<literal>mls/equal</literal> during creation.</para>
</listitem>
<listitem>
- <para><literal>security.mac.mls.revocation_enabled</literal>
- is used to revoke access to objects after their label
- changes to a label of a lower grade.</para>
+ <para><varname>security.mac.mls.revocation_enabled</varname>
+ revokes access to objects after their label changes to a
+ label of a lower grade.</para>
</listitem>
<listitem>
- <para><literal>security.mac.mls.max_compartments</literal>
- is used to set the maximum number of compartment levels
- with objects; basically the maximum compartment number
- allowed on a system.</para>
+ <para><varname>security.mac.mls.max_compartments</varname>
+ sets the maximum number of compartment levels allowed on a
+ system.</para>
</listitem>
</itemizedlist>
- <para>To manipulate the <acronym>MLS</acronym> labels, the
- &man.setfmac.8; command has been provided. To assign a label
- to an object, issue the following command:</para>
+ <para>To manipulate the <acronym>MLS</acronym> labels, use
+ &man.setfmac.8;. To assign a label to an object, issue the
+ following command:</para>
<screen>&prompt.root; <userinput>setfmac mls/5 test</userinput></screen>
<para>To get the <acronym>MLS</acronym> label for the file
- <filename>test</filename> issue the following command:</para>
+ <filename>test</filename>, issue the following command:</para>
<screen>&prompt.root; <userinput>getfmac test</userinput></screen>
- <para>This is a summary of the <acronym>MLS</acronym>
- policy's features. Another approach is to create a master
- policy file in <filename class="directory">/etc</filename>
- which specifies the <acronym>MLS</acronym> policy information
- and to feed that file into the <command>setfmac</command>
- command. This method will be explained after all policies are
- covered.</para>
+ <para>Another approach is to create a master policy file in
+ <filename class="directory">/etc/</filename> which specifies the
+ <acronym>MLS</acronym> policy information and to feed that file
+ to <command>setfmac</command>. This method will be explained
+ after all policies are covered.</para>
<sect2>
<title>Planning Mandatory Sensitivity</title>
- <para>With the Multi-Level Security Policy Module, an
- administrator plans for controlling the flow of sensitive
- information. By default, with its block read up block write
- down nature, the system defaults everything to a low state.
- Everything is accessible and an administrator
- slowly changes this during the configuration stage; augmenting
- the confidentiality of the information.</para>
-
- <para>Beyond the three basic label options above, 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 familiarized with
- words, for instance classifications such as
- <literal>Confidential</literal>, <literal>Secret</literal>,
- and <literal>Top Secret</literal>. Some administrators might
- just create different groups based on project levels.
- Regardless of classification method, a well thought out plan
- must exist before implementing such a restrictive
- policy.</para>
-
- <para>Some example situations for this security policy module
- could be an e-commerce web server, a file server holding
+ <para>When using the MLS policy module, an administrator plans
+ to control the flow of sensitive information. The default
+ <literal>block read up block write down</literal> sets
+ everything to a low state. Everything is accessible and an
+ administrator slowly augments the confidentiality of the
+ information during the configuration stage;.</para>
+
+ <para>Beyond the three basic label options, an administrator may
+ group users and groups as required to block the information
+ flow between them. It might be easier to look at the
+ information in clearance levels using descriptive words, such
+ as classifications of <literal>Confidential</literal>,
+ <literal>Secret</literal>, and <literal>Top Secret</literal>.
+ Some administrators instead create different groups based on
+ project levels. Regardless of the classification method, a
+ well thought out plan must exist before implementing such a
+ restrictive policy.</para>
+
+ <para>Some example situations for the MLS policy module
+ include an e-commerce web server, a file server holding
critical company information, and financial institution
- environments. The most unlikely place would be a personal
- workstation with only two or three users.</para>
+ environments.</para>
</sect2>
</sect1>
@@ -1453,25 +1318,24 @@ test: biba/high</screen>
</indexterm>
<para>Module name: <filename>mac_biba.ko</filename></para>
- <para>Kernel configuration line:
- <literal>options MAC_BIBA</literal></para>
+ <para>Kernel configuration line: <literal>options
+ MAC_BIBA</literal></para>
<para>Boot option: <literal>mac_biba_load="YES"</literal></para>
<para>The &man.mac.biba.4; module loads the <acronym>MAC</acronym>
- Biba policy. This policy works much like that of the
+ Biba policy. This policy is similar to the
<acronym>MLS</acronym> policy with the exception that the rules
- for information flow
- are slightly reversed. This is said to prevent the downward
- flow of sensitive information whereas the <acronym>MLS</acronym>
- policy prevents the upward flow of sensitive information; thus,
- much of this section can apply to both policies.</para>
+ for information flow are slightly reversed. This is to prevent
+ the downward flow of sensitive information whereas the
+ <acronym>MLS</acronym> policy prevents the upward flow of
+ sensitive information. Much of this section can apply to both
+ policies.</para>
<para>In Biba environments, an <quote>integrity</quote> label is
set on each subject or object. These labels are made up of
- hierarchal grades, and non-hierarchal components. As an
- object's or subject's grade ascends, so does its
- integrity.</para>
+ hierarchical grades and non-hierarchical components. As an
+ grade ascends, so does its integrity.</para>
<para>Supported labels are <literal>biba/low</literal>,
<literal>biba/equal</literal>, and <literal>biba/high</literal>;
@@ -1501,59 +1365,60 @@ test: biba/high</screen>
</listitem>
</itemizedlist>
- <para>Biba provides for:</para>
+ <para>Biba provides:</para>
<itemizedlist>
<listitem>
<para>Hierarchical integrity level with a set of non
- hierarchical integrity categories;</para>
+ hierarchical integrity categories.</para>
</listitem>
<listitem>
- <para>Fixed rules: no write up, no read down (opposite of
- <acronym>MLS</acronym>). A subject can have write access
+ <para>Fixed rules are <literal>no write up, no read
+ down</literal>, the opposite of
+ <acronym>MLS</acronym>. A subject can have write access
to objects on its own level or below, but not above.
Similarly, a subject can have read access to objects on
- its own level or above, but not below;</para>
+ its own level or above, but not below.</para>
</listitem>
<listitem>
- <para>Integrity (preventing inappropriate modification of
- data);</para>
+ <para>Integrity by preventing inappropriate modification of
+ data.</para>
</listitem>
<listitem>
- <para>Integrity levels (instead of MLS sensitivity
- levels).</para>
+ <para>Integrity levels instead of MLS sensitivity
+ levels.</para>
</listitem>
</itemizedlist>
<para>The following <command>sysctl</command> tunables can
- be used to manipulate the Biba policy.</para>
+ be used to manipulate the Biba policy:</para>
<itemizedlist>
<listitem>
- <para><literal>security.mac.biba.enabled</literal> may be used
- to enable/disable enforcement of the Biba policy on the
+ <para><varname>security.mac.biba.enabled</varname> is used
+ to enable or disable enforcement of the Biba policy on the
target machine.</para>
</listitem>
<listitem>
- <para><literal>security.mac.biba.ptys_equal</literal> may be
+ <para><varname>security.mac.biba.ptys_equal</varname> is
used to disable the Biba policy on &man.pty.4;
devices.</para>
</listitem>
<listitem>
- <para><literal>security.mac.biba.revocation_enabled</literal>
- will force the revocation of access to objects if the label
+ <para><varname>security.mac.biba.revocation_enabled</varname>
+ forces the revocation of access to objects if the label
is changed to dominate the subject.</para>
</listitem>
</itemizedlist>
<para>To access the Biba policy setting on system objects, use
- the <command>setfmac</command> and <command>getfmac</command>
- commands:</para>
+ <command>setfmac</command> and
+ <command>getfmac</command>:</para>
<screen>&prompt.root; <userinput>setfmac biba/low test</userinput>
&prompt.root; <userinput>getfmac test</userinput>
@@ -1562,44 +1427,41 @@ test: biba/low</screen>
<sect2>
<title>Planning Mandatory Integrity</title>
- <para>Integrity, different from sensitivity, guarantees that the
- information will never be manipulated by untrusted parties.
- This includes information passed between subjects, objects,
- and both. It ensures that users will only be able to modify
- and in some cases even access information they explicitly need
- to.</para>
+ <para>Integrity, which is different from sensitivity, guarantees
+ that the information will never be manipulated by untrusted
+ parties. This includes information passed between subjects,
+ objects, and both. It ensures that users will only be able to
+ modify or access information they explicitly need to.</para>
<para>The &man.mac.biba.4; security policy module permits an
- administrator to address which files and programs a user or
- users may see and invoke while assuring that the programs and
- files are free from threats and trusted by the system for that
- user, or group of users.</para>
+ administrator to address which files and programs a user may
+ see and invoke while assuring that the programs and files are
+ free from threats and trusted by the system for that
+ user.</para>
<para>During the initial planning phase, an administrator must
be prepared to partition users into grades, levels, and areas.
- Users will be blocked access not only to data but programs
+ Users will be blocked access not only to data but to programs
and utilities both before and after they start. The system
will default to a high label once this policy module is
enabled, and it is up to the administrator to configure the
different grades and levels for users. Instead of using
- clearance levels as described above, 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. While other
- users would be grouped into other categories such as testers,
- designers, or just ordinary users and would only be permitted
- read access.</para>
-
- <para>With its natural security control, a lower integrity
- subject is unable to write to a higher integrity subject; a
- higher integrity subject cannot observe or read a lower
- integrity object. Setting a label at the lowest possible
- grade could make it inaccessible to subjects. Some
- prospective environments for this security policy module
- would include a constrained web server, development and test
- machine, and source code repository. A less useful
- implementation would be a personal workstation, a machine
- used as a router, or a network firewall.</para>
+ clearance levels, a good planning method could include topics.
+ For instance, only allow developers modification access to the
+ source code repository, source code compiler, and other
+ development utilities. Other users would be grouped into
+ other categories such as testers, designers, or end users and
+ would only be permitted read access.</para>
+
+ <para>A lower integrity subject is unable to write to a higher
+ integrity subject and a higher integrity subject cannot
+ observe or read a lower integrity object. Setting a label at
+ the lowest possible grade could make it inaccessible to
+ subjects. Some prospective environments for this security
+ policy module would include a constrained web server, a
+ development and test machine, and a source code repository. A
+ less useful implementation would be a personal workstation, a
+ machine used as a router, or a network firewall.</para>
</sect2>
</sect1>
@@ -1611,8 +1473,9 @@ test: biba/low</screen>
</indexterm>
<para>Module name: <filename>mac_lomac.ko</filename></para>
- <para>Kernel configuration line:
- <literal>options MAC_LOMAC</literal></para>
+ <para>Kernel configuration line: <literal>options
+ MAC_LOMAC</literal></para>
+
<para>Boot option: <literal>mac_lomac_load="YES"</literal></para>
<para>Unlike the <acronym>MAC</acronym> Biba policy, the
@@ -1621,13 +1484,11 @@ test: biba/low</screen>
any integrity rules.</para>
<para>The <acronym>MAC</acronym> version of the Low-watermark
- integrity policy, not to be confused with the older
- &man.lomac.4; implementation, works almost identically to Biba,
- but with the exception of using floating labels to support
- subject demotion via an auxiliary grade compartment. This
- secondary compartment takes the form of
- <literal>[auxgrade]</literal>. When assigning a lomac policy
- with an auxiliary grade, it should look a little bit like:
+ integrity policy works almost identically to Biba, but with the
+ exception of using floating labels to support subject demotion
+ via an auxiliary grade compartment. This secondary compartment
+ takes the form <literal>[auxgrade]</literal>. When assigning
+ a LOMAC policy with an auxiliary grade, use the syntax
<literal>lomac/10[2]</literal> where the number two (2) is the
auxiliary grade.</para>
@@ -1635,25 +1496,23 @@ test: biba/low</screen>
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. This is the
- <literal>[auxgrade]</literal> option discussed above, thus the
+ high integrity objects using <literal>[auxgrade]</literal>. The
policy may provide for greater compatibility and require less
initial configuration than Biba.</para>
<sect2>
<title>Examples</title>
- <para>Like the Biba and <acronym>MLS</acronym> policies;
- the <command>setfmac</command> and <command>setpmac</command>
- utilities may be 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>
&prompt.root; <userinput>getfmac /usr/home/trhodes</userinput> lomac/high[low]</screen>
- <para>Notice the auxiliary grade here is <literal>low</literal>,
- this is a feature provided only by the <acronym>MAC</acronym>
- LOMAC policy.</para>
+ <para>The auxiliary grade <literal>low</literal> is a feature
+ provided only by the <acronym>MAC</acronym> LOMAC
+ policy.</para>
</sect2>
</sect1>
@@ -1664,28 +1523,25 @@ test: biba/low</screen>
<primary>Nagios in a MAC Jail</primary>
</indexterm>
- <para>The following demonstration will implement a secure
+ <para>The following demonstration implements a secure
environment using various <acronym>MAC</acronym> modules
- with properly configured policies. This is only a test and
- should not be considered the complete answer to everyone's
- security woes. Just implementing a policy and ignoring it
- never works and could be disastrous in a production
- environment.</para>
-
- <para>Before beginning this process, the
- <literal>multilabel</literal> option must be set on each file
- system as stated at the beginning of this chapter. Not doing
- so will result in errors. While at it, ensure that the
- <filename role="package">net-mngt/nagios-plugins</filename>,
+ with properly configured policies. This is only a test as
+ implementing a policy and ignoring it could be disastrous in a
+ production environment.</para>
+
+ <para>Before beginning this process, <option>multilabel</option>
+ must be set on each file system as not doing so will result in
+ errors. This example assumes that <filename
+ role="package">net-mngt/nagios-plugins</filename>,
<filename role="package">net-mngt/nagios</filename>, and
- <filename role="package">www/apache22</filename> ports are all
+ <filename role="package">www/apache22</filename> are all
installed, configured, and working correctly.</para>
<sect2>
- <title>Create an insecure User Class</title>
+ <title>Create an Insecure User Class</title>
<para>Begin the procedure by adding the following user class
- to the <filename>/etc/login.conf</filename> file:</para>
+ to <filename>/etc/login.conf</filename>:</para>
<programlisting>insecure:\
:copyright=/etc/COPYRIGHT:\
@@ -1711,13 +1567,12 @@ test: biba/low</screen>
:ignoretime@:\
:label=biba/10(10-10):</programlisting>
- <para>And adding the following line to the default user
- class:</para>
+ <para>Add the following line to the default user class:</para>
<programlisting>:label=biba/high:</programlisting>
- <para>Once this is completed, the following command must be
- issued to rebuild the database:</para>
+ <para>Next, issue the following command to rebuild the
+ database:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
</sect2>
@@ -1725,9 +1580,8 @@ test: biba/low</screen>
<sect2>
<title>Boot Configuration</title>
- <para>Do not reboot yet, just add the following lines to
- <filename>/boot/loader.conf</filename> so the required
- modules will load during system initialization:</para>
+ <para>Add the following lines to
+ <filename>/boot/loader.conf</filename>:</para>
<programlisting>mac_biba_load="YES"
mac_seeotheruids_load="YES"</programlisting>
@@ -1744,9 +1598,8 @@ mac_seeotheruids_load="YES"</programlisting>
<para>All user accounts that are not <username>root</username>
or system users will now require a login class. The login
class is required otherwise users will be refused access
- to common commands such as &man.vi.1;.
- The following <command>sh</command> script should do the
- trick:</para>
+ to common commands such as &man.vi.1;. The following
+ <command>sh</command> script should do the trick:</para>
<screen>&prompt.root; <userinput>for x in `awk -F: '($3 &gt;= 1001) &amp;&amp; ($3 != 65534) { print $1 }' \</userinput>
<userinput>/etc/passwd`; do pw usermod $x -L default; done;</userinput></screen>
@@ -1763,8 +1616,7 @@ mac_seeotheruids_load="YES"</programlisting>
<sect2>
<title>Create the Contexts File</title>
- <para>A contexts file should now be created; the following
- example file should be placed in
+ <para>A contexts file should now be created as
<filename>/etc/policy.contexts</filename>.</para>
<programlisting># This is the default BIBA policy for this system.
@@ -1802,28 +1654,28 @@ mac_seeotheruids_load="YES"</programlisting>
/usr/local/etc/apache biba/10
/usr/local/etc/apache/* biba/10</programlisting>
- <para>This policy will enforce security by setting restrictions
+ <para>This policy enforces security by setting restrictions
on the flow of information. In this specific configuration,
- users, <username>root</username> and others, should never be
+ users, including <username>root</username>, should never be
allowed to access <application>Nagios</application>.
Configuration files and processes that are a part of
<application>Nagios</application> will be completely self
contained or jailed.</para>
- <para>This file may now be read into our system by issuing the
+ <para>This file will be read by the system by issuing the
following command:</para>
<screen>&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput>
&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput></screen>
<note>
- <para>The above file system layout may be different depending
- on environment; however, it must be run on every single file
+ <para>The above file system layout will differ depending
+ upon the environment and must be run on every file
system.</para>
</note>
- <para>The <filename>/etc/mac.conf</filename> file requires
- the following modifications in the main section:</para>
+ <para><filename>/etc/mac.conf</filename> requires the following
+ modifications in the main section:</para>
<programlisting>default_labels file ?biba
default_labels ifnet ?biba
@@ -1855,45 +1707,43 @@ default_labels socket ?biba</programlisting>
</indexterm>
<para>Ensure that the web server and
- <application>Nagios</application> will not be started
- on system initialization, and reboot. Ensure the
+ <application>Nagios</application> will not be started on
+ system initialization and reboot. Ensure the
<username>root</username> user cannot access any of the files
in the <application>Nagios</application> configuration
directory. If <username>root</username> can issue an
&man.ls.1; command on <filename>/var/spool/nagios</filename>,
- then something is wrong. Otherwise a <quote>permission
+ something is wrong. Otherwise a <quote>permission
denied</quote> error should be returned.</para>
<para>If all seems well, <application>Nagios</application>,
<application>Apache</application>, and
- <application>Sendmail</application> can now be started in a
- way fitting of the security policy. The following commands
- will make this happen:</para>
+ <application>Sendmail</application> can now be started:</para>
<screen>&prompt.root; <userinput>cd /etc/mail &amp;&amp; make stop &amp;&amp; \
setpmac biba/equal make start &amp;&amp; setpmac biba/10\(10-10\) apachectl start &amp;&amp; \
setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></screen>
<para>Double check to ensure that everything is working
- properly. If not, check the log files or error messages. Use
- the &man.sysctl.8; utility to disable the &man.mac.biba.4;
- security policy module enforcement and try starting everything
- again, like normal.</para>
+ properly. If not, check the log files for error messages.
+ Use &man.sysctl.8; to disable the &man.mac.biba.4; security
+ policy module enforcement and try starting everything again as
+ usual.</para>
<note>
- <para>The <username>root</username> user can change the
- security enforcement and edit the configuration files
- without fear. The following command will permit the
- degradation of the security policy to a lower grade for a
- newly spawned shell:</para>
+ <para>The <username>root</username> user can still change the
+ security enforcement and edit its configuration files. The
+ following command will permit the degradation of the
+ security policy to a lower grade for a newly spawned
+ shell:</para>
<screen>&prompt.root; <userinput>setpmac biba/10 csh</userinput></screen>
<para>To block this from happening, force the user into a
- range via &man.login.conf.5;. If &man.setpmac.8; attempts
+ range using &man.login.conf.5;. If &man.setpmac.8; attempts
to run a command outside of the compartment's range, an
error will be returned and the command will not be executed.
- In this case, setting root to
+ In this case, set root to
<literal>biba/high(high-high)</literal>.</para>
</note>
</sect2>
@@ -1902,15 +1752,14 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<sect1 id="mac-userlocked">
<title>User Lock Down</title>
- <para>This example considers a relatively small, fewer than fifty
- users, storage system. Users would have login capabilities,
- and be permitted to not only store data but access resources
- as well.</para>
+ <para>This example considers a relatively small storage system
+ with fewer than fifty users. Users will have login
+ capabilities, and be permitted to store data and access
+ resources.</para>
- <para>For this scenario, the &man.mac.bsdextended.4; mixed with
- &man.mac.seeotheruids.4; could co-exist and block access not
- only to system objects, but to hide user processes as
- well.</para>
+ <para>For this scenario, the &man.mac.bsdextended.4; and
+ &man.mac.seeotheruids.4; policy modules could co-exist and block
+ access to system objects while hiding user processes.</para>
<para>Begin by adding the following line to
<filename>/boot/loader.conf</filename>:</para>
@@ -1918,25 +1767,24 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<programlisting>mac_seeotheruids_load="YES"</programlisting>
<para>The &man.mac.bsdextended.4; security policy module may be
- activated through the use of the following rc.conf
- variable:</para>
+ activated by adding this line to
+ <filename>/etc/rc.conf</filename>:</para>
<programlisting>ugidfw_enable="YES"</programlisting>
<para>Default rules stored in
<filename>/etc/rc.bsdextended</filename> will be loaded at
- system initialization; however, the default entries may need
+ system initialization. However, the default entries may need
modification. Since this machine is expected only to service
users, everything may be left commented out except the last
- two. These will force the loading of user owned system objects
- by default.</para>
+ two lines in order to force the loading of user owned system
+ objects by default.</para>
<para>Add the required users to this machine and reboot. For
testing purposes, try logging in as a different user across
- two consoles. Run the <command>ps aux</command> command to
- see if processes of other users are visible. Try to run
- &man.ls.1; on another users home directory, it should
- fail.</para>
+ two consoles. Run <command>ps aux</command> to see if processes
+ of other users are visible. Verify that running &man.ls.1; on
+ another user's home directory fails.</para>
<para>Do not try to test with the <username>root</username> user
unless the specific <command>sysctl</command>s have been
@@ -1945,9 +1793,8 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<note>
<para>When a new user is added, their &man.mac.bsdextended.4;
rule will not be in the ruleset list. To update the ruleset
- quickly, simply unload the security policy module and reload
- it again using the &man.kldunload.8; and &man.kldload.8;
- utilities.</para>
+ quickly, unload the security policy module and reload it again
+ using &man.kldunload.8; and &man.kldload.8;.</para>
</note>
</sect1>
@@ -1958,30 +1805,23 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<primary>MAC Troubleshooting</primary>
</indexterm>
- <para>During the development stage, a few users reported problems
- with normal configuration. Some of these problems
- are listed below:</para>
+ <para>This section discusses common configuration issues.</para>
<sect2>
- <title>The <option>multilabel</option> option cannot be enabled
- on <filename>/</filename></title>
+ <title><option>multilabel</option> cannot be enabled on
+ <filename>/</filename></title>
- <para>The <option>multilabel</option> flag does not stay
+ <para>The<option>multilabel</option> flag does not stay
enabled on my root (<filename>/</filename>) partition!</para>
- <para>It seems that one out of every fifty users has this
- problem, indeed, we had this problem during our initial
- configuration. Further observation of this so called
- <quote>bug</quote> has lead me to believe that it is a
- result of either incorrect documentation or misinterpretation
- of the documentation. Regardless of why it happened, the
- following steps may be taken to resolve it:</para>
+ <para>The following steps may resolve this transient
+ error:</para>
<procedure>
<step>
<para>Edit <filename>/etc/fstab</filename> and set the root
- partition at <option>ro</option> for read-only.</para>
+ partition to <option>ro</option> for read-only.</para>
</step>
<step>
@@ -1995,7 +1835,7 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
</step>
<step>
- <para>Reboot the system into normal mode.</para>
+ <para>Reboot the system.</para>
</step>
<step>
@@ -2007,7 +1847,7 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
</step>
<step>
- <para>Double-check the output from the
+ <para>Double-check the output from
<command>mount</command> to ensure that
<option>multilabel</option> has been properly set on the
root file system.</para>
@@ -2016,12 +1856,12 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
</sect2>
<sect2>
- <title>X11 Server Will Not Start After
+ <title>Xorg Server Will Not Start After
<acronym>MAC</acronym></title>
<para>After establishing a secure environment with
<acronym>MAC</acronym>, I am no longer able to start
- X!</para>
+ Xorg!</para>
<para>This could be caused by the <acronym>MAC</acronym>
<literal>partition</literal> policy or by a mislabeling in
@@ -2035,25 +1875,21 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<literal>partition</literal> policy may be the culprit.
Try setting the user's class back to the
<literal>default</literal> class and rebuild the database
- with the <command>cap_mkdb</command> command. If this
- does not alleviate the problem, go to step two.</para>
+ with <command>cap_mkdb</command>. If this does not
+ alleviate the problem, go to step two.</para>
</step>
<step>
<para>Double-check the label policies. Ensure that the
- policies are set correctly for the user in question, the
- X11 application, and
- the <filename class="directory">/dev</filename>
- entries.</para>
+ policies are set correctly for the user, the Xorg
+ application, and the <filename
+ class="directory">/dev</filename> entries.</para>
</step>
<step>
<para>If neither of these resolve the problem, send the
- error message and a description of your environment to
- the TrustedBSD discussion lists located at the
- <ulink url="http://www.TrustedBSD.org">TrustedBSD</ulink>
- website or to the &a.questions;
- mailing list.</para>
+ error message and a description of the environment to
+ the &a.questions; mailing list.</para>
</step>
</procedure>
</sect2>
@@ -2062,52 +1898,50 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></s
<title>Error: &man..secure.path.3; cannot stat
<filename>.login_conf</filename></title>
- <para>When I attempt to switch from the
+ <para>When a user attempts to switch from the
<username>root</username> user to another user in the system,
the error message <errorname>_secure_path: unable to state
.login_conf</errorname> appears.</para>
<para>This message is usually shown when the user has a higher
- label setting then that of the user whom they are attempting
- to become. For instance a user on the system,
- <username>joe</username>, has a default label of
- <option>biba/low</option>. The <username>root</username>
- user, who has a label of <option>biba/high</option>, cannot
- view <username>joe</username>'s home directory. This will
- happen regardless if <username>root</username> has used the
- <command>su</command> command to become
- <username>joe</username>, or not. In this scenario, the Biba
- integrity model will not permit <username>root</username> to
- view objects set at a lower integrity level.</para>
+ label setting than that of the user they are attempting to
+ become. For instance, <username>joe</username> has a default
+ label of <option>biba/low</option>. The
+ <username>root</username> user, who has a label of
+ <option>biba/high</option>, cannot view
+ <username>joe</username>'s home directory. This will happen
+ whether or not <username>root</username> has used
+ <command>su</command> to become <username>joe</username> as
+ the Biba integrity model will not permit
+ <username>root</username> to view objects set at a lower
+ integrity level.</para>
</sect2>
<sect2>
<title>The <username>root</username> username is broken!</title>
<para>In normal or even single user mode, the
- <username>root</username> is not recognized. The
- <command>whoami</command> command returns 0 (zero) and
+ <username>root</username> is not recognized,
+ <command>whoami</command> returns 0 (zero), and
<command>su</command> returns <errorname>who are
- you?</errorname>. What could be going on?</para>
+ you?</errorname>.</para>
<para>This can happen if a labeling policy has been disabled,
either by a &man.sysctl.8; or the policy module was unloaded.
- If the policy is being disabled or has been temporarily
- disabled, then the login capabilities database needs to be
- reconfigured with the <option>label</option> option being
- removed. Double check the <filename>login.conf</filename>
- file to ensure that all <option>label</option> options have
- been removed and rebuild the database with the
- <command>cap_mkdb</command> command.</para>
-
- <para>This may also happen if a policy restricts access to the
- <filename>master.passwd</filename> file or database. Usually
- caused by an administrator altering the file under a label
- which conflicts with the general policy being used by the
- system. In these cases, the user information would be read
- by the system and access would be blocked as the file has
- inherited the new label. Disable the policy via a
- &man.sysctl.8; and everything should return to normal.</para>
+ If the policy is disabled, the login capabilities database
+ needs to be reconfigured with <option>label</option> removed.
+ Double check <filename>login.conf</filename> to ensure that
+ all <option>label</option> options have been removed and
+ rebuild the database with <command>cap_mkdb</command>.</para>
+
+ <para>This may also happen if a policy restricts access to
+ <filename>master.passwd</filename>. This is usually caused by
+ an administrator altering the file under a label which
+ conflicts with the general policy being used by the system.
+ In these cases, the user information would be read by the
+ system and access would be blocked as the file has inherited
+ the new label. Disable the policy using &man.sysctl.8; and
+ everything should return to normal.</para>
</sect2>
</sect1>
</chapter>