svn commit: r40904 - head/en_US.ISO8859-1/books/handbook/mac
Dru Lavigne
dru at FreeBSD.org
Thu Feb 7 15:05:38 UTC 2013
Author: dru
Date: Thu Feb 7 15:05:37 2013
New Revision: 40904
URL: http://svnweb.freebsd.org/changeset/doc/40904
Log:
This patch addresses the following:
- removes etc. and i.e.
- fixes some title capitalization
- fixes incorrect grammar and overuse of ;
- fixes verb tense from future to active
- fixes redundancy
- general rewording to make a densely written dense subject slightly less dense
- link added for trustedbsd website
- spell out of acronyms introduced on first instance in section and used as acronym for all other instances
- remove reference to trustedbsd mailing lists as these have only seen spam posts in past 6 years
- reference to SEBSD was removed as does not exist
- reference to deprecated lomac confusion removed
- fix varname tags
- note added that as of 8.x, MAC is in GENERIC
Approved by: bcr (mentor)
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 Thu Feb 7 15:02:30 2013 (r40903)
+++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Thu Feb 7 15:05:37 2013 (r40904)
@@ -27,44 +27,42 @@
</indexterm>
<para>&os; 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,32 +393,29 @@
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>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
+ integrity file to a high integrity label.</footnote> The
system administrator may use the following commands to
overcome this:</para>
@@ -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>
-
- <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>
+ 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>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>In many cases, the <option>multilabel</option> may not
- need to be set at all. Consider the following situation and
- security model:</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>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
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-head
mailing list