Whitespace and slight rewording changes. No new content added,
translators may safely ignore.
This commit is contained in:
parent
018c1d855e
commit
71031a6595
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=22516
1 changed files with 40 additions and 38 deletions
|
@ -26,7 +26,7 @@
|
|||
TrustedBSD project based on the &posix;.1e draft. Two of the most
|
||||
significant new security mechanisms are file system Access Control
|
||||
Lists (<acronym>ACLs</acronym>) and Mandatory Access Control
|
||||
(<acronym>MAC</acronym>). Mandatory Access Control allows
|
||||
(<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, while others provide
|
||||
|
@ -36,7 +36,7 @@
|
|||
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 IPC permissions on &os;).</para>
|
||||
file and System V <acronym>IPC</acronym> permissions on &os;).</para>
|
||||
|
||||
<para>This chapter will focus on the
|
||||
Mandatory Access Control Framework (MAC Framework), and a set
|
||||
|
@ -124,7 +124,7 @@
|
|||
<title>What Will Not Be Covered</title>
|
||||
|
||||
<para>This chapter covers a broad range of security issues relating
|
||||
to the <acronym>MAC</acronym> framework, however, the
|
||||
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
|
||||
<acronym>MAC</acronym> framework have specific characteristics
|
||||
|
@ -249,18 +249,19 @@
|
|||
|
||||
<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 policies provided by
|
||||
the system as a whole. The various security policies 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 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 is different
|
||||
then 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>
|
||||
the best use of the policies 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
|
||||
is different then 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 choose
|
||||
|
@ -386,11 +387,11 @@
|
|||
<option>multilabel</option> option may be passed 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 permitting
|
||||
access to that group or a higher group level.</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
|
||||
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>
|
||||
|
@ -401,8 +402,8 @@
|
|||
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
|
||||
restrict the <username>root</username> user as well. Basic control over
|
||||
objects will then be released to the group but
|
||||
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
|
||||
by policies such as Biba and <acronym>MLS</acronym>.</para>
|
||||
|
@ -420,8 +421,8 @@
|
|||
&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>
|
||||
<command>setpmac</command> command is used to set the labels
|
||||
on system subjects. Observe:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
|
||||
|
||||
|
@ -431,16 +432,17 @@
|
|||
&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 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 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 system administrator
|
||||
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 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 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 system administrator
|
||||
may use the following commands to overcome this:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput>
|
||||
|
@ -903,9 +905,9 @@ test: biba/high</screen>
|
|||
directory from the username <username>user1</username>.</para>
|
||||
|
||||
<para>In place of <username>user1</username>, the
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<note>
|
||||
<para>The <username>root</username> user will be unaffected
|
||||
|
@ -2128,8 +2130,8 @@ XXX
|
|||
<step>
|
||||
<para>Check the error message; if the user is in the
|
||||
<literal>insecure</literal> class, the
|
||||
<literal>partition</literal> policy may be the culprit. Try
|
||||
setting the user's class back to the
|
||||
<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>
|
||||
|
@ -2181,8 +2183,8 @@ XXX
|
|||
<para>In normal or even single user mode, the
|
||||
<username>root</username> is not recognized. The
|
||||
<command>whoami</command> command returns 0 (zero) and
|
||||
<command>su</command> returns <errorname>who are you?</errorname>. What
|
||||
could be going on?</para>
|
||||
<command>su</command> returns <errorname>who are you?</errorname>.
|
||||
What could be going on?</para>
|
||||
|
||||
<para>This can happen if a labeling policy has been disabled,
|
||||
either by a &man.sysctl.8; or the policy module was unloaded.
|
||||
|
|
Loading…
Reference in a new issue