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:
Tom Rhodes 2006-04-21 06:37:42 +00:00
parent f1fc6567eb
commit 5e095db7d2
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=27600

View file

@ -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">