os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Be more clear on the difference between a security policy and a security

Browse source 
policy module.  Make a few grammatical fixes while I am here.
This commit is contained in:
Tom Rhodes 2005-04-22 19:34:21 +00:00
parent fa63510b7c
commit 24c7f51615
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=24366
1 changed files with 51 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

102
en_US.ISO8859-1/books/handbook/mac/chapter.sgml
View file

@ -43,19 +43,19 @@
<para>This chapter will focus on the
Mandatory Access Control Framework (MAC Framework), and a set
of pluggable policy modules implementing various security
policies.</para>
of pluggable security policy modules enableing various security
mechanisms.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
<para>What <acronym>MAC</acronym> modules are currently
included in &os; and their associated policies.</para>
<para>What <acronym>MAC</acronym> security policy modules are currently
included in &os; and their associated mechanisms.</para>
</listitem>
<listitem>
<para>What <acronym>MAC</acronym> policy modules implement as
<para>What <acronym>MAC</acronym> security policy modules implement as
well as the difference between a labeled and non-labeled
policy.</para>
</listitem>
@ -66,8 +66,8 @@
</listitem>
<listitem>
<para>How to configure the different policies used by the
<acronym>MAC</acronym> modules.</para>
<para>How to configure the different security policy modules included with the
<acronym>MAC</acronym> framework.</para>
</listitem>
<listitem>
@ -104,7 +104,7 @@
<warning>
<para>The improper use of the
information in this chapter may cause loss of access to the system,
information in this chapter 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
@ -116,7 +116,7 @@
<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 these policies takes
on a production system. Implementing the various security policy modules takes
a good deal of thought. 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
@ -128,13 +128,13 @@
<para>This chapter covers a broad range of security issues relating
to the <acronym>MAC</acronym> framework; however, the
development of new <acronym>MAC</acronym> policies
will not be covered. A number of modules included with 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 the &man.mac.test.4;,
&man.mac.stub.4; and &man.mac.none.4; modules/policies.
For more information on these modules and the various
&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 pages.</para>
</sect2>
</sect1>
@ -155,7 +155,7 @@
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
policy.</para>
security policy.</para>
</listitem>
<listitem>
@ -169,11 +169,11 @@
<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
to be a confidentiality stamp; when a label is placed on
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: while
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>
@ -194,7 +194,7 @@
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 labeled policies.</para>
only applies to security policy modules which support labeling.</para>
</listitem>
<listitem>
@ -252,14 +252,14 @@
<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 policies provided by
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 policies is to blend them together, by loading
several security policy modules at a time, for a multi-layered
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 policies are in effect to keep security in check. This
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
@ -273,30 +273,30 @@
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 policies offered by the framework.</para>
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 policies; and
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 policies. Some environments
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; policies might make good starting points. In other
&man.mac.biba.4; policy modules might make good starting points. In other
cases, strict confidentiality of file system objects might
be required. Policies such as &man.mac.bsdextended.4;
be required. Policy modules such as &man.mac.bsdextended.4;
and &man.mac.mls.4; exist for this purpose.</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 of choice for these situations. But what should 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
@ -309,17 +309,17 @@
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 policies provided by
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 the fear of information
appropriate areas without fear of information
leakage.</para>
<para>Thus, each policy has a unique way of dealing with
the overall security of a system. Policy selection should be based
<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 policies offered by
the system. Understanding the different security policy modules offered by
the <acronym>MAC</acronym> framework will help administrators
choose the best policies for their situations.</para>
@ -334,10 +334,10 @@
<caution>
<para>While the various manual pages for <acronym>MAC</acronym>
modules state that they may be built into the kernel,
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, but care must be taken
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>
@ -354,8 +354,8 @@
<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 loaded, and that
policies interpret their attributes in pretty different
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
@ -368,18 +368,18 @@
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 policy,
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 policies which support the labeling feature in
<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, you
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>
policies.</para>
policy modules.</para>
<para>Within single label file system environments, only one label may be
used on objects. This will enforce one set of
@ -402,9 +402,9 @@
<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 <username>root</username> is the one in control and who
configures the policy so that users are placed in the
appropriate categories/access levels. Alas, many policies can
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
@ -414,7 +414,7 @@
<sect2>
<title>Label Configuration</title>
<para>Virtually all aspects of label policy configuration
<para>Virtually all aspects of label policy module configuration
will be performed using the base system utilities. These
commands provide a simple interface for object or subject
configuration or the manipulation and verification of
@ -455,14 +455,14 @@
test: biba/high</screen>
<para>As we see above, <command>setpmac</command>
can be used to override the policy's settings by assigning
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 policies, 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>
@ -554,10 +554,10 @@ test: biba/high</screen>
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 that uses labels
by use of login classes. Every policy module that uses labels
will implement the user class setting.</para>
<para>An example entry containing every policy is listed
<para>An example entry containing every policy module setting is displayed
below:</para>
<programlisting>default:\
@ -589,7 +589,7 @@ test: biba/high</screen>
<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.
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>
@ -643,7 +643,7 @@ test: biba/high</screen>
<literal>biba/high(low-high)</literal> the entire label should
be quoted; otherwise an error will be returned.</para>
<para>Each policy which supports labeling has some tunable
<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
@ -655,7 +655,7 @@ test: biba/high</screen>
<sect2>
<title>Singlelabel or Multilabel?</title>
<!-- Stopped here with my edits -->
<para>By default the system will use the
<option>singlelabel</option> option. But what does this
mean to the administrator? There are several differences