Two new basic sections better describing MLS and Biba. I'll re-read these
later, just to ensure I picked up everything.
This commit is contained in:
parent
f1fc6567eb
commit
5e095db7d2
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=27600
1 changed files with 67 additions and 14 deletions
|
@ -1440,15 +1440,32 @@ test: biba/high</screen>
|
|||
feed that file into the <command>setfmac</command> command. This
|
||||
method will be explained after all policies are covered.</para>
|
||||
|
||||
<para>Observations: an object with lower clearance is unable to
|
||||
observe higher clearance processes. A basic policy would be
|
||||
to enforce <literal>mls/high</literal> on everything not to be
|
||||
read, even if it needs to be written. Enforce
|
||||
<literal>mls/low</literal> on everything not to be written, even
|
||||
if it needs to be read. And finally enforce
|
||||
<literal>mls/equal</literal> on the rest. All users marked
|
||||
<literal>insecure</literal> should be set at
|
||||
<literal>mls/low</literal>.</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 read
|
||||
down nature, the system defaults everything to a low state.
|
||||
Everything is pretty much accessible and an administrator
|
||||
slowly changes this during the configuration stage.</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 critical
|
||||
company information, and financial institution environments.
|
||||
The most unlikely place would be a personal workstation with
|
||||
only two or three users.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mac-biba">
|
||||
|
@ -1563,11 +1580,47 @@ test: biba/high</screen>
|
|||
&prompt.root; <userinput>getfmac test</userinput>
|
||||
test: biba/low</screen>
|
||||
|
||||
<para>Observations: 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.</para>
|
||||
<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>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 users.</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
|
||||
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 to access 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.</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>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mac-lomac">
|
||||
|
|
Loading…
Reference in a new issue