Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!clyde!cbatt!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!pur-ee!uiucdcs!uiucuxc!gswd-vms!andy From: andy@gswd-vms.UUCP Newsgroups: comp.unix.wizards Subject: Re: Slaying Gould dragon with a wooden Message-ID: <1700002@gswd-vms> Date: Wed, 5-Nov-86 16:00:00 EST Article-I.D.: gswd-vms.1700002 Posted: Wed Nov 5 16:00:00 1986 Date-Received: Sun, 16-Nov-86 07:23:45 EST References: <161@unisec.UUCP> Lines: 189 Nf-ID: #R:unisec.UUCP:161:gswd-vms:1700002:000:7515 Nf-From: gswd-vms.UUCP!andy Nov 5 15:00:00 1986 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 " 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).