COPS and Robbers UN*X System Security In the last few years, computer security has received a great deal more attention than it has in the past. Compu- terized break-ins and criminal activity, once merely the product of the imagination of science fiction writers, has became a fairly common occurence in both commercial and academic circles. In this paper, I will go over the prob- lems that face any multiuser computing system, then discuss how these problems apply to UNIX[1] specifically, and finally present in detail a suite of programs that were developed in an attempt to address some of the main problems that could be solved via software. UNIX, although con- sidered to be a fairly secure operating system ([Wood 88], [Duff 89], etc), has the advantage of having many published works ([Grampp and Morris 84], [Bishop 83], etc) on the problems that a computing site can have with security, and in addition, on how a UNIX system administrator might make his/her system more secure by monitoring various aspects of his/her UNIX site. This, combined with UNIX's popularity, make it an ideal target for a software security system to operate on. In this report I am not going to discuss specific ways of breaking into a given UNIX machine (for a more detailed description on how to compromise UNIX security, see either [Baldwin88], [Bishop83], [Wood & Kochran 86], or [Grampp & Morris 84]) -- instead, I will concentrate on how to improve and strengthen the potentially good security of a generic UNIX system by means of a software toolkit that examines the weaker areas of UNIX that are either traditionally ignored (due to the time constraints or ignorance of the system administrators) or are simply reoccurring problems that need to be watched over. In addition, this report is not meant for UNIX neophytes -- although a great deal of proficiency is not needed to read this report and use the programs described herein, a familiarity with basic UNIX features -- the file system and file permission modes for example -- and commands such as awk,grep,sed as well as a working knowledge of shell and C programming are necessary to _________________________ 9 [1] Although originally designed and developed by Ken Thompson and Dennis Ritchie of AT&T, UNIX has grown far beyond its' original design and now numerous companies market their own "flavor" of UNIX. When I use the term UNIX in this paper, I don't mean merely AT&T's version, but instead I mean the majority of the most popular varieties, made by developers at Berkely, Sun, and a host of other manufacturers. I believe UNIX is still a trademark of Bell Laboratories. 9 February 19, 1991 - 2 - understand the internal workings of the security system described in this paper. Although there is no reasonable way that all security problems can be solved (at least not with a software solu- tion) on any arbitrary UNIX system, administrators and sys- tem programs can be assisted by a software security tool. The Computer Oracle Password and Security system (COPS) that will be described in this paper is just such a device. The COPS system is a collection of programs and shell scripts that attempt to address as many of these problems as possi- ble in an efficient, portable, and above all in a reliable and safe way. The main goal of COPS is one of prevention; it tries to anticipate and eliminate security problems by making sure people don't get a chance to compromise security in the first place. Alerting the administrators of a poten- tial intruder or that a virus has infected the system is beyond the scope of the present system, although with work with such capabilities could be added ([Bauer and Koblentz 88] and [Duff 89].) To understand the reason COPS might check any specific problem, a look at computer security problems in general is in order. The problems listed below are not meant to be inclusive, but they are indicative of the myriad types of dilemmas a typical computer multiuser system might encounter: 1) Administrators, system programmers, and computer operators. The very people that (should) worry the most about security are sometimes the ones that are the least concerned. Carelessness is one of the main culprits; a mis- take by a user might cause little or no problem, but when someone with no restrictions (or almost none) on their com- puter activity makes a mistake, a security hole can result. "I can trust my users" is a fine statement to make -- but can you trust your users' friends? How about the users of computers that are networked to yours? New software, sys- tems, or procedures can facilitate extra problems; a comput- ing staff is often ill or completely non-trained on new techniques and software. Too often "RTFM" is the only training that they will ever receive. Programs that are created for in-house use are often ill-documented and not debugged thoroughly, and when users other than the author start to use/abuse the program, problems can result. Espe- cially misunderstood, even by experienced UNIX system pro- grammers, is the SUID program or, worse yet, the SUID shell script ([Bishop 83].) When a user says that his/her password was forgotten (or any other account/security related prob- lem), what checks are made to verify that the person is really the owner of that account? Are users that are secu- rity problems kept track of, so that repeated abuses of the system will result in punitive action? Does your site even have a security policy? And of course, the last straw is February 19, 1991 - 3 - that most system administrators simply have too much other work to do than to constantly check the system for potential security flaws -- let alone to double-check that any work done by other system programmers has been done correctly. These are the actions that often get left unsaid and undone. A UNIX environment has no special defenses against this kind of "attack". Fortunately, a number of these potential problems (unless catastrophic in scope) are not only correctable, but are easy to detect with a software toolkit such as COPS. Even the most careful UNIX guru will periodi- cally make a mistake; COPS has been designed to aid in her/his never ending battle against the forces of darkness. 2) Physical security. This is perhaps the most frus- trating of all possible problems because it effects all com- puter systems and is often the hardest to safeguard against. Even if the software is secure, even if the system adminis- trators are alert to potential problems, what happens if a user walks up to the root console and starts typing? Does the night janitorial staff let anyone into the machine room without proper identification? Who has access to the key that opens up the computing center? Are terminals that are logged on left unguarded or unlocked? Are passwords written on or near a users terminal or desk? No software in the world can help against human nature or carelessness. Reiterating to your staff and users that terminals should not be left alone or unguarded and that passwords (espe- cially root) should not be typed in front of unfriendly (and in this case, _everyone_ is your enemy) eyes would be a good start. A simple analogy: since you would never give the keys to the company car away, why on earth would you give away the keys to your computer, which is certainly worth a hell of a lot more time and money (although it may not get as good mileage on the interstate.) Common sense goes a long ways to help prevent this kind of risk. 3) Authentication. What is authentication? All modern computing systems that have capabilities for multiple users have a means of identifying who is using the computer at any given time. A common means of identification is by using a password; and since the inception of this idea, poor passwords have been a perennial problem. People have a ten- dency to use their own name, or their social security number, or some other common word, name, or phrase for a password. The problem then arises when an unauthorized user wants to access clandestine information, he/she simply tries one of these simple passwords until a successful match is found. Other problems with authentication? What computer hosts are "trusted" and allow users to log in from other machines without any further authentication? Are incorrect login attempts kept and/or monitored so as to allow February 19, 1991 - 4 - administrators to keep track of any unusual activity? What about "Trojan horses" -- programs that can steal passwords and the privileges that a user owns -- is there a program or a administrative method that detects a potential 'horse? Fortunately UNIX systems again have some fairly good tools to aid in this fight. Although finding simple pass- words is indeed a trivial task, forcing the users on a sys- tem to use passwords that are harder to guess is also trivial, by either modifying the mechanism that gets/gives the password to the user, and/or by having the system administrators run a simple password detector periodically, and notifying users if their password is deemed too obvious. The crypt command, although proven to be insecure for a knowledgeable and resourceful attacker ([Reed and Weinberger 84], [Baldwin 86]), does offer an added shield against most unauthorized users. Logs can be kept of...
kopia23