ch17.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,284 行 · 第 1/5 页

<DL>
	<DD>Using mathematics and set theory, the model precisely defines the notion of secure
	state, fundamental modes of access, and the rules for granting subjects specific
	modes of access to objects. Finally, a theorem is proven to demonstrate that the
	rules are security-preserving operations, so that the application of any sequence
	of the rules to a system that is in a secure state will result in the system entering
	a new state that is also secure. This theorem is known as the Basic Security Theorem.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Find the Orange Book online at <A
	HREF="http://www.v-one.com/newpages/obook.html"><TT>http://www.v-one.com/newpages/obook.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>This sounds complicated, but is isn't really. The model prescribes a series of
&quot;rules&quot; of conduct. These rules of conduct may apply both to human beings
(as in how military top secret and secret messages are sent) or it may apply to the
levels of access allowed in a given system. If you are deeply interested in learning
about the Bell and LaPadula security model, you should acquire the Orange Book. Moreover,
there is an excellent paper available that will not only help you understand the
basics of that security model but weaknesses or quirks within it. That paper is titled
&quot;A Security Model for Military Message Systems.&quot; The authors are Carl Landwher,
Constance L. Heitmeyer, and John McLean. The paper proposes some new concepts with
regard to such systems and contrasts these new approaches to the Bell and LaPadula
security model. This paper reduces the complexity of the subject matter, allowing
the user to easily understand concepts.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;A Security Model
	for Military Message Systems&quot; can be found online at <A 
HREF="http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1984landwehr-tocs.ps"><TT>http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1984landwehr-tocs.ps</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Another excellent paper, &quot;On Access Checking in Capability-Based Systems&quot;
(by Richard Y. Kain and C. E. Landwehr) demonstrates how some conditions and environments
<I>cannot</I> conform to the Bell and LaPadula security model. The information discussed
can fill out your knowledge of these types of security models.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Kain and Landwehr's paper,
	&quot;On Access Checking in Capability-Based Systems,&quot; can be found online at
	<A HREF="http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1987landwehr-tse.ps"><TT>http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1987landwehr-tse.ps</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Trusted XENIX has very granular access control, audit capabilities, and access
control lists. In addition, the system recognizes four levels of secure users (or
privileged users):

<UL>
	<LI>System security administrator
	<LI>Secure operator
	<LI>Account administrator
	<LI>Auditor
</UL>

<P>Only one of these (auditor) can alter the logs. This is serious security at work.
From this level of systems security, the focus is on who, as opposed to what, is
operating the system. In other words, operating systems like this do not trust users.
Therefore, the construct of the system relies on strict security access policies
instituted for humans by humans. The only way to crack such a system is if someone
on the inside is &quot;dirty.&quot; Each person involved in system maintenance is
compartmentalized against the rest. (For example, the person who tends to the installation
has his own account and this account [The Trusted System Programmer] can only operate
in single-user mode.) The design, therefore, provides a very high level of accountability.
Each so-called trusted user is responsible for a separate part of system security.
In order for system security to be totally compromised, these individuals must act
in collusion (which is not a likely contingency).</P>
<P>Versions of secure UNIX also exist that occupy a slightly lower level on the EPL.
These are extremely secure systems as well and are more commonly found in real-life
situations. XTS STOP and TIS Trusted XENIX amount to extreme security measures, way
beyond what the average organization or business would require. Such systems are
reserved for the super- paranoid. B1 systems abound and they are quite secure. Some
of the vendors that provide B1 products are as follows:

<UL>
	<LI>Amdahl Corporation (UTS/MLS, version 2.1.5+)
	<LI>Digital Equipment Corporation (DEC) (SEVMS VAX version 6.1)
	<LI>DEC (SEVMS VAX and Alpha version 6.1)
	<LI>DEC (ULTRIX MLS+ version 2.1)
	<LI>Harris Computer Systems Corporation (CX/SX 6.2.1)
	<LI>Hewlett Packard Corporation (HP-UX BLS release 9.0.9+)
	<LI>Silicon Graphics, Inc. (Trusted IRIX/B release 4.0.5EPL)
	<LI>Unisys Corporation (OS 1100/2200 release SB4R7)
	<LI>Cray Research, Inc. (Trusted UNICOS 8.0)
	<LI>Informix Software, Inc. (INFORMIX-Online/Secure 5.0)
	<LI>Oracle Corporation (Trusted Oracle7)
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Again, I have listed only the latest
	versions of these products. In many instances, earlier versions are also B1 compliant.
	Please check the EPL for specifics on earlier versions. 
<HR>


</BLOCKQUOTE>

<P>This book does not treat implementation and maintenance of secure UNIX distributions.
My reasons for this are pretty basic. First, there was not enough space to treat
this subject. Second, if you use secure UNIX on a daily basis, it is you (and not
I) who probably should have written this book, for your knowledge of security is
likely very deep. So, having quickly discussed secure UNIX (a thing that very few
of you will ever grapple with), I would like to move forward to detail some practical
information.</P>
<P>We are going to start with one machine and work out way outward. (Not a very novel
idea, but one that at least will add some order to this chapter.)
<H2><FONT COLOR="#000077"><B>Beginning at the Beginning</B></FONT></H2>
<P>Some constants can be observed on all UNIX platforms. Securing any system begins
at the time of installation (or at least it should). At the precise moment of installation,
the only threat to your security consists of out-of-the-box holes (which are generally
well known) and the slim possibility of a trojan horse installed by one of the vendor's
programmers. (This contingency is so slight that you would do best not to fret over
it. If such a trojan horse exists, news will soon surface about it. Furthermore,
there is really no way for you to check whether such a trojan exists. You can apply
all the MD5 you like and it will not matter a hoot. If the programmer involved had
the necessary privileges and access, the cryptographic checksums will ring true,
even when matched against the vendor's database of checksums. The vendor has no knowledge
that the trojan horse existed, and therefore, he went with what he thought was the
most secure distribution possible. These situations are so rare that you needn't
worry about them.)
<H2><FONT COLOR="#000077"><B>Console Security</B></FONT></H2>
<P>Before all else, your first concern runs to the people who have physical access
to the machine. There are two types of those people:

<UL>
	<LI>Those that will occupy physical proximity, but have no privileged access<BR>
	<BR>
	
	<LI>Those that will both occupy physical proximity and have privileged access
</UL>

<P>The first group, if they tamper with your box, will likely cause minimal damage,
but could easily cause denial of service. They can do this through simple measures,
such as disconnecting the SCSI cables and disabling the Ethernet connection. However,
in terms of actual access, their avenues will be slim so long as you set your passwords
immediately following installation.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Immediately upon installation, set
	the <TT>root</TT> password. Many distributions, like Sun's SunOS or Solaris, will
	request that you do so. It is generally the last option presented prior to either
	reboot (SunOS) or bootup (Solaris). However, many distributions do not force a choice
	prior to first boot. Linux Slackware is one such distribution. AIX (AIX 4.<I>x</I>
	in particular, which boots directly to the Korn shell) is another. If you have installed
	such a system, set the <TT>root</TT> password immediately upon logging in. 
<HR>


</BLOCKQUOTE>

<P>Next, there are several things you need to check. Those who have physical proximity
but no privilege could still compromise your security. After setting the <TT>root</TT>
password, the first question you should ask yourself is whether your system supports
a single-user mode. If so, can you disable it or restrict its use? Many systems support
single-user mode. For example, certain DECstations (the 3100, in particular) will
allow you to specify your boot option:

<DL>
	<DD>When a DEC workstation is first shipped, its console system operates in privileged
	command mode. If you do nothing to change from privileged mode, there will be no
	console command restrictions. Anyone with physical console access can activate any
	console command, the most vulnerable being interactive booting.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from CIAC-2303, <I>The Console Password for DEC Workstations</I> by
	Allan L. Van Lehn.<I> </I>This excellent paper can be found online at <A HREF="http://ciac.llnl.gov/ciac/documents/"><TT>http://ciac.llnl.gov/ciac/documents/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Interactive booting will get them to a single-user mode and that hole should be
shut immediately after installation. You can set the console password on a DEC workstation.
<H2><FONT COLOR="#000077"><B>Where Is the Box Located?</B></FONT></H2>
<P>Next, note that the box is only as secure as its location. Certainly, you would
not place a machine with sensitive information in a physical location where malicious
users can have unrestricted access to it. &quot;Unrestricted access&quot; in this
context means access where users could potentially have time, without fear of detection,
to take off the cover or otherwise tamper with the hardware. Such tampering could
lead to compromise.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Some machines have physical weaknesses
	that are also inherent to the PC platform. On certain workstations, it is trivial
	to disable the <TT>PROM</TT> password. For instance, removing the nvram chip on Indigo
	workstations will kill the <TT>PROM</TT> password. 
<HR>


</BLOCKQUOTE>

<P>As noted in RFC 1244:

<DL>
	<DD>It is a given in computer security that if the system itself is not physically
	secure, nothing else about the system can be considered secure. With physical access
	to a machine, an intruder can halt the machine, bring it back up in privileged mode,
	replace or alter the disk, plant trojan horse programs or take any number of other
	undesirable (and hard to prevent) actions. Critical communications links, important
	servers, and other key machines should be located in physically secure areas.
</DL>

<P>So your machine should be located in a safe place. It should be exposed to as
little physical contact with untrusted personnel as possible. It should also have
a <TT>root</TT> password and a console password, if applicable.
<H2><FONT COLOR="#000077"><B>Securing Your Installation Media</B></FONT></H2>
<P>Your installation media should be kept in a secure place. Remember that installation
media can be used to compromise the system. For example, our more mature readers
may remember that this can be done with certain versions of AT&amp;T UNIX, particularly
SVR3 and V/386. This technique involves inserting the boot floppy, booting from it
(as opposed to a fixed disk), and choosing the &quot;magic mode&quot; option. This
presents a means through which to obtain a shell.</P>
<P>Remember that when you are installing, you <I>are</I> <TT>root</TT>. For those
distributions that require a boot disk as part of the installation procedure, this
is especially important.</P>
<P>Installations that occur solely via CD-ROM are less likely to offer a malicious
user leveraged access. However, be advised that these types of installations also
pose a risk. You must think as the malicious user thinks. If your SPARC is sitting