Slaying Gould dragon with a wooden

[andy at gswd-vms.UUCP]

SUMMARY: Darryl Wagoner broke into the system and deserves
	 (will get) the TV.

         Some of the concerns expressed were results of errors
         made at the show by booth personnel who had performed
         a 'quick' UTX/32S (*) installation.

         Security involves H/W, S/W *and* PEOPLE!

         Gould is still HIGHLY confident in the security of UTX/32S
         and is willing to 'up the ante'.


This episode has very nicely illustrated one of the key issues 
associated with security --- if one is overly enamored with the
technological aspects and shortchanges the people aspects, the
'system' will be just as susceptible to penetration as it would be
without the 'security' technology. For this reminder, we thank
Mr. Wagoner.


So how is it that Darryl broke into the 'system' so easily?

Darryl noticed that the restricted environment mechanism could
not be defeated so he approached the problem using the "unwary-
system-administrator" bag of tricks combined with several trojan
horses.

Off-hand, it may seem that what Darryl did wasn't fair.  However,
it was quite fair, and furthermore, this method of penetration is
rather common and is usually quite a bit easier to use than
defeating the software mechanisms.  No secure system will remain
secure for very long if  the administrators and the users are not
security conscious.

As part of the C2 requirements set by the National Computer
Security Center, good system administration manuals are required
to train the system administrators about good security practices
and warn them about common threats.

For instance, the UTX/32S System Administrator's Guide (SAG)
says:
     A secure operating system shares the responsibility of
     enforcing security with the system hardware and system
     administrators.  Each of these three elements -
     operating system, hardware, and administrators - must
     be trusted; this is, they must be relied upon to uphold
     the security policy."

In the case of UNIX expo, the system administrators made a few
*mistakes*.  The two main mistakes were putting "." as the first
thing in their PATH and executing a user's program for him, as
superuser no less!  Losing the audit trail file also ranks up
there with the first two.

The system administrator's guide also says:

     When you are working as superuser, any command or file
     executed, directly or indirectly, may run with
     superuser privileges.  Therefore, avoid running any
     file that could have been created or modified by a
     general user.  It is imperative that superuser
     privileges be used as sparingly as possible.

Unfortunately, our staff at the booth at the EXPO faithfully
followed the instructions for a piece of third party S/W that
explicitly asked that "." be put in the PATH. This documentation
is being fixed.  Securely administering a system is not easy.  
This is, however, a weak excuse, and certainly a fatal excuse in 
an environment where security is critical.  System administrators 
have to be aware of potential security threats.

There is a place for software mechanisms in the protection of a
system.  UTX/32S has a number of mechanisms, mostly transparent
to the user, like the restricted environment, a stronger access
policy for /dev devices, crosschecks on passwd and group files,
and the removal of the setuid bit.

There are a number of other security mechanisms that can be used
and a number of different ways to build a secure UNIX.  Darryl
feels that the setuid bit is necessary for it to remain UNIX.
This is a valid viewpoint held by many.  There are equally many
on the other side of the fence claiming that removing the setuid
mechanisms is necessary.  Security is not free.

In UTX/32S the setuid bit has been removed.  Yes, this has
been painful but there are just too many ways to subvert UNIX
using the setuid mechanism.   Those mechanisms that required a
setuid mechanism of some kind have been replaced by what we
call trusted servers, secure sockets, and clients.

There were a number of other problems that Darryl had with
UTX/32S.

     sucsh(8)
	 Darryl thought the command was called cshsu(8) rather than
	 sucsh(8).  However, there was a time at the show that 
	 sucsh(8) was disabled by the system administrator.

         Darryl said that "." should not have been in the PATH.
         He is *absolutely* right.  Putting "." at the end of
	 the PATH may be a good compromise.  We are also considering
	 having the sucsh shell totally ignore ".".  The sucsh(8) 
	 command does not have "." in its PATH.  However, the system
         administrators explicitly put "." in their PATH for
         reasons stated above.  This should not have been done!!!

     Audit Trail
         As delivered on the boot tape, the UTX/32S audit trail 
	 mechanism does not remove the audit file at boot time.

         Again, the problem was due to a system administration
         error.  When the system was rebooted, the audit trail
         file was removed because the system administrator had
         put "rm <audit file>" in the rc file right before the
	 audit system was enabled.

     kill character
         Darryl suggested having a kill character or secure
         attention key to kill all processes and get a trusted
         login.  This is known as a trusted path, is required
         at higher security levels and will be in a subsequent
         (higher security level) release of UTX/32S.


Now to address Darryl's overall question, is a trojan horse a
legitimate way to break into a system.

First you have to define the word "system".  Since security is a
combination of the computer and the administrative procedures,
the security "system" may also be defined as both.  In this case,
a trojan horse, bribing the security guard to let you in to the
console room, or adding trap doors at the software development
site previous to software completion, are all legitimate means of
breaking into a system.

It should also be noted that the C2 level (at which UTX/32S
is being certified), exists primarily to protect non-malicious 
users from each other and to protect the system from user mistakes.  
Only at B1 and above is the malicious user a required consideration.

In the real world, the bottom line is that if someone wants to
access your computer's data, anything is fair game.  This is why
physical security and proper administrative procedures are so
critical.



SO   ....

THE CHALLENGE REMAINS:

An offer is extended to Mr. Wagoner to try again *without* our assistance.
If he successfully gets into a file that we will create, he will get a VCR
to go along with his new TV!!!!

p.s. For those who feel that they can break UTX/32S and wish to have a 
go at it, please send 'e-mail' to the following address for details.
(The stakes are a color TV plus the VCR [Thanks to Darryl])

{ucbvax,decvax}!pur-ee!gould!securix

We request the following info:
Name
Title
Company
Address
Phone #
Best network address



James E. Clark  ... Director, Systems Marketing, Gould Inc
		        	{ucbvax,decvax}!pur-ee!gould!jclark
Andy Schuelke   ... Project Manager, Secure Systems, Gould Inc
				{ucbvax,decvax}!pur-ee!gould!aschuelke
Mikel Matthews	... Project Scientist, Secure Systems, Gould Inc
				{ucbvax,decvax}!pur-ee!gould!mmatthews





-------- 
* UTX/32S is a secure version of Gould's UTX/32  operating system
and is certifiable at the C2 level as defined in the Department
of Defense Trusted Computer System Evaluation Criteria (TCSEC).