svn commit: r44358 - head/en_US.ISO8859-1/books/handbook/mac
Dru Lavigne
dru at FreeBSD.org
Wed Mar 26 15:52:53 UTC 2014
Author: dru
Date: Wed Mar 26 15:52:52 2014
New Revision: 44358
URL: http://svnweb.freebsd.org/changeset/doc/44358
Log:
Slight shuffling of content to improve flow of MAC chapter.
Editorial review of Synopsis and Key Terms.
More commits to come.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Wed Mar 26 15:44:14 2014 (r44357)
+++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Wed Mar 26 15:52:52 2014 (r44358)
@@ -21,20 +21,19 @@
<see>MAC</see>
</indexterm>
- <para>&os; 5.X introduced new security extensions from the
- <link xlink:href="http://www.trustedbsd.org">TrustedBSD
- Project</link> 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. MAC allows new
- access control modules to be loaded, implementing new security
+ <para>&os; supports security extensions
+ based on the &posix;.1e draft. These
+ security mechanisms include file system Access
+ Control Lists (<xref linkend="fs-acl"/>) and Mandatory Access
+ Control (<acronym>MAC</acronym>). <acronym>MAC</acronym> allows
+ access control modules to be loaded in order to implement security
policies. Some modules provide protections for a narrow subset
of the system, hardening a particular service. Others provide
comprehensive labeled security across all subjects and objects.
The mandatory part of the definition indicates that enforcement
of controls is performed by administrators and the operating
system. This is in contrast to the default security mechanism
- of Discretionary Access Control (<acronym>DAC</acronym> where
+ 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
@@ -109,28 +108,23 @@
understanding, proper design, and thorough testing.</para>
</warning>
- <sect2>
- <title>What Will Not Be Covered</title>
-
- <para>This chapter covers a broad range of security issues
- relating to the <acronym>MAC</acronym> framework. The
+ <para>While this chapter covers a broad range of security issues
+ relating to the <acronym>MAC</acronym> framework, the
development of new <acronym>MAC</acronym> security policy
modules will not be covered. A number of security policy
modules included with the <acronym>MAC</acronym> framework
have specific characteristics which are provided for both
- testing and new module development. 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, refer to their manual
- pages.</para>
- </sect2>
+ testing and new module development. Refer to
+ &man.mac.test.4;, &man.mac.stub.4; and &man.mac.none.4;
+ for more information on these security policy modules and
+ the various mechanisms they provide.</para>
</sect1>
<sect1 xml:id="mac-inline-glossary">
- <title>Key Terms in This Chapter</title>
+ <title>Key Terms</title>
- <para>Before reading this chapter, a few key terms must be
- explained:</para>
+ <para>The following key terms are used when referring to the
+ <acronym>MAC</acronym> framework:</para>
<itemizedlist>
<listitem>
@@ -144,21 +138,18 @@
</listitem>
<listitem>
- <para><emphasis>high-watermark</emphasis>: this type of
- policy permits the raising of security levels for the
- purpose of accessing higher level information. In most
- cases, the original level is restored after the process
- is complete. Currently, the &os; <acronym>MAC</acronym>
- framework does not include this type of policy.</para>
- </listitem>
-
- <listitem>
<para><emphasis>integrity</emphasis>: the level of trust which
can be placed on data. As the integrity of the data is
elevated, so does the ability to trust that data.</para>
</listitem>
<listitem>
+ <para><emphasis>level</emphasis>: the increased or decreased
+ setting of a security attribute. As the level increases,
+ its security is considered to elevate as well.</para>
+ </listitem>
+
+ <listitem>
<para><emphasis>label</emphasis>: a security attribute which
can be applied to files, directories, or other items in the
system. It could be considered a confidentiality stamp.
@@ -173,23 +164,8 @@
</listitem>
<listitem>
- <para><emphasis>level</emphasis>: the increased or decreased
- setting of a security attribute. As the level increases,
- its security is considered to elevate as well.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>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>: this property is a file
- system option which can be set in single user mode using
+ 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>
@@ -198,129 +174,71 @@
</listitem>
<listitem>
+ <para><emphasis>single label</emphasis>: a policy where the
+ entire file system uses one label to enforce access control
+ over the flow of data. Whenever <option>multilabel</option>
+ is not set, all files will conform to the same label
+ setting.</para>
+ </listitem>
+
+ <listitem>
<para><emphasis>object</emphasis>: an entity through which
information flows under the direction of a
<emphasis>subject</emphasis>. This includes directories,
files, fields, screens, keyboards, memory, magnetic storage,
printers or any other data storage or moving device. An
object is a data container or a system resource. Access to
- an <emphasis>object</emphasis> effectively means access to
+ an object effectively means access to
its data.</para>
</listitem>
<listitem>
+ <para><emphasis>subject</emphasis>: any active entity that
+ causes information to flow between
+ <emphasis>objects</emphasis> such as a user, user process,
+ or system process. On &os;, this is almost always a
+ thread acting in a process on behalf of a user.</para>
+ </listitem>
+
+ <listitem>
<para><emphasis>policy</emphasis>: a collection of rules
which defines how objectives are to be achieved. A
- <emphasis>policy</emphasis> usually documents how certain
- 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
+ policy usually documents how certain
+ items are to be handled. This chapter considers a
+ policy to be a collection of rules which controls
the flow of data and information and defines who has access
to that data and information.</para>
</listitem>
<listitem>
- <para><emphasis>sensitivity</emphasis>: usually used when
- discussing Multilevel Security <acronym>MLS</acronym>. A
- sensitivity level describes how important or secret the data
- should be. As the sensitivity level increases, so does the
- importance of the secrecy, or confidentiality, of the
- data.</para>
+ <para><emphasis>high-watermark</emphasis>: this type of
+ policy permits the raising of security levels for the
+ purpose of accessing higher level information. In most
+ cases, the original level is restored after the process
+ is complete. Currently, the &os; <acronym>MAC</acronym>
+ framework does not include this type of policy.</para>
</listitem>
<listitem>
- <para><emphasis>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>
+ <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>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>
+ <para><emphasis>sensitivity</emphasis>: usually used when
+ discussing Multilevel Security (<acronym>MLS</acronym>). A
+ sensitivity level describes how important or secret the data
+ should be. As the sensitivity level increases, so does the
+ importance of the secrecy, or confidentiality, of the
+ data.</para>
</listitem>
</itemizedlist>
</sect1>
- <sect1 xml:id="mac-initial">
- <title>Explanation of MAC</title>
-
- <para>With all of these new terms in mind, consider how the
- <acronym>MAC</acronym> framework augments the security of
- the system as a whole. The various security policy modules
- provided by the <acronym>MAC</acronym> framework could be used
- to protect the network and file systems or to block users from
- accessing certain ports and sockets. Perhaps the best use of
- the policy modules is to load several security policy modules at
- a time in order to provide a <acronym>MLS</acronym> environment.
- This approach differs from a hardening policy, which typically
- hardens elements of a system which are used only for specific
- purposes. The downside to <acronym>MLS</acronym> is increased
- administrative overhead.</para>
-
- <para>The overhead is minimal when compared to the lasting effect
- of a framework which provides the ability to pick and choose
- which policies are required for a specific configuration and
- which keeps performance overhead down. The reduction of support
- for unneeded policies can increase the overall performance of
- the system as well as offer flexibility of choice. A good
- implementation would consider the overall security requirements
- and effectively implement the various security policy modules
- offered by the framework.</para>
-
- <para>A system utilizing <acronym>MAC</acronym> guarantees that a
- user will not be permitted to change security attributes at
- will. All user utilities, programs, and scripts must work
- within the constraints of the access rules provided by the
- selected security policy modules and 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. 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>
-
- <caution>
- <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>
-
<sect1 xml:id="mac-understandlabel">
<title>Understanding MAC Labels</title>
@@ -735,6 +653,77 @@ test: biba/high</screen>
&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>
+
+ <para>Consider how the
+ <acronym>MAC</acronym> framework augments the security of
+ the system as a whole. The various security policy modules
+ provided by the <acronym>MAC</acronym> framework could be used
+ to protect the network and file systems or to block users from
+ accessing certain ports and sockets. Perhaps the best use of
+ the policy modules is to load several security policy modules at
+ a time in order to provide a <acronym>MLS</acronym> environment.
+ This approach differs from a hardening policy, which typically
+ hardens elements of a system which are used only for specific
+ purposes. The downside to <acronym>MLS</acronym> is increased
+ administrative overhead.</para>
+
+ <para>The overhead is minimal when compared to the lasting effect
+ of a framework which provides the ability to pick and choose
+ which policies are required for a specific configuration and
+ which keeps performance overhead down. The reduction of support
+ for unneeded policies can increase the overall performance of
+ the system as well as offer flexibility of choice. A good
+ implementation would consider the overall security requirements
+ and effectively implement the various security policy modules
+ offered by the framework.</para>
+
+ <para>A system utilizing <acronym>MAC</acronym> guarantees that a
+ user will not be permitted to change security attributes at
+ will. All user utilities, programs, and scripts must work
+ within the constraints of the access rules provided by the
+ selected security policy modules and 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. 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>
+
+ <caution>
+ <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>
<sect1 xml:id="mac-modules">
More information about the svn-doc-head
mailing list