![[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 [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 17.security|
Return to security.ms CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 17.security |
1.1 root 1: .\" @(#)security.ms 5.2 (Berkeley) 5/14/86
2: .\"
3: .EH 'SMM:17-%''On the Security of \s-2UNIX\s+2'
4: .OH 'On the Security of \s-2UNIX\s+2''SMM:17-%'
5: .ND June 10, 1977
6: .TL
7: On the Security of UNIX
8: .AU
9: Dennis M. Ritchie
10: .AI
11: .MH
12: .PP
13: Recently there has been much interest in the security
14: aspects of operating systems and software.
15: At issue is the ability
16: to prevent undesired
17: disclosure of information, destruction of information,
18: and harm to the functioning of the system.
19: This paper discusses the degree of security which can be provided
20: under the
21: .UX
22: system and offers a number of hints
23: on how to improve security.
24: .PP
25: The first fact to face is that
26: .UX
27: was not developed with
28: security, in any realistic sense, in mind;
29: this fact alone guarantees a vast number of holes.
30: (Actually the same statement can be made with respect
31: to most systems.)
32: The area of security in which
33: .UX
34: is theoretically weakest is
35: in protecting against crashing or at least crippling
36: the operation of the system.
37: The problem here is not mainly in uncritical
38: acceptance of bad parameters to system calls\(em
39: there may be bugs in this area, but none are known\(em
40: but rather in lack of checks for excessive
41: consumption of resources.
42: Most notably, there is no limit on the amount of disk
43: storage used, either in total space allocated or in
44: the number of files or directories.
45: Here is a particularly ghastly shell sequence guaranteed
46: to stop the system:
47: .DS
48: while : ; do
49: mkdir x
50: cd x
51: done
52: .DE
53: Either a panic will occur because all the i-nodes
54: on the device are used up, or all the disk blocks will
55: be consumed, thus preventing anyone from writing files
56: on the device.
57: .PP
58: In this version of the system,
59: users are prevented from creating more than
60: a set number of processes simultaneously,
61: so unless users are in collusion it is unlikely that any one
62: can stop the system altogether.
63: However, creation of 20 or so CPU or disk-bound jobs
64: leaves few resources available for others.
65: Also, if many large jobs are run simultaneously,
66: swap space may run out, causing a panic.
67: .PP
68: It should be evident that excessive consumption of disk
69: space, files, swap space, and processes can easily occur
70: accidentally in malfunctioning programs
71: as well as at command level.
72: In fact
73: .UX
74: is essentially defenseless against this kind of
75: abuse,
76: nor is there any easy fix.
77: The best that can be said is that it is generally
78: fairly
79: easy to detect what has happened when disaster
80: strikes,
81: to identify the user responsible,
82: and take appropriate action.
83: In practice,
84: we have found that difficulties
85: in this area are rather rare,
86: but we have not been faced with malicious users,
87: and enjoy a fairly generous supply of
88: resources which have served to cushion us against
89: accidental overconsumption.
90: .PP
91: The picture is considerably brighter
92: in the area of protection of information
93: from unauthorized perusal and destruction.
94: Here the degree of security seems (almost)
95: adequate theoretically, and the problems lie
96: more in the necessity for care in the actual use of
97: the system.
98: .PP
99: Each
100: .UX
101: file has associated with it
102: eleven bits of protection information
103: together with a user identification number and a user-group
104: identification number
105: (UID and GID).
106: Nine of the protection bits
107: are used to specify independently
108: permission to read, to write, and to execute the file
109: to the user himself, to members of the user's
110: group, and to all other users.
111: Each process generated
112: by or for a user has associated with
113: it an effective UID and a real UID, and an effective and real GID.
114: When an attempt is made
115: to access the file for reading, writing, or execution,
116: the user process's effective UID is compared
117: against the file's UID; if a match is obtained,
118: access is granted provided the read, write, or execute
119: bit respectively for the user himself is
120: present.
121: If the UID for the file and for the process fail to match,
122: but the GID's do match, the group bits are used; if the GID's
123: do not match, the bits for other users are tested.
124: The last two bits of each file's protection information,
125: called the set-UID and set-GID bits,
126: are used only when the
127: file is executed as a program.
128: If, in this case, the set-UID bit is on for the file,
129: the effective UID for the process is changed to the UID
130: associated with the file; the change persists
131: until the process terminates or until the UID
132: changed again by another execution of a set-UID file.
133: Similarly the effective group ID of a process is changed
134: to the GID associated with a file
135: when that file is executed and has the set-GID bit set.
136: The real UID and GID of a process do not change
137: when any file is executed,
138: but only as the result of a privileged system
139: call.
140: .PP
141: The basic notion of the set-UID and set-GID
142: bits is that one may write a program which is executable
143: by others and which maintains files accessible to others only
144: by that program.
145: The classical example is the game-playing program which
146: maintains records of the scores of its players.
147: The program itself has to read and write the score file,
148: but
149: no one but the game's sponsor can be allowed
150: unrestricted access to the file lest they manipulate
151: the game to their own advantage.
152: The solution is to
153: turn on the set-UID bit of the
154: game
155: program.
156: When, and only when, it is invoked
157: by players of the game, it may update the score file
158: but ordinary programs executed by others cannot
159: access the score.
160: .PP
161: There are a number of special cases involved
162: in determining access permissions.
163: Since executing a directory as a program is a meaningless
164: operation, the execute-permission
165: bit, for directories, is taken instead to mean
166: permission to search the directory for a given file
167: during the scanning of a path name;
168: thus if a directory has execute permission but no read
169: permission for a given user, he may access files
170: with known names in the directory,
171: but may not read (list) the entire contents of the
172: directory.
173: Write permission on a directory is interpreted to
174: mean that the user may create and delete
175: files in that directory;
176: it is impossible
177: for any user to write directly into any directory.
178: .PP
179: Another, and from the point of view of security, much
180: more serious special case is that there is a ``super user''
181: who is able to read any file and write any non-directory.
182: The super-user is also able to change the protection
183: mode and the owner UID and GID of any file
184: and to invoke privileged system calls.
185: It must be recognized that the mere notion of
186: a super-user is a theoretical, and usually
187: practical, blemish on any protection scheme.
188: .PP
189: The first necessity for a secure system
190: is of course arranging that all files and directories
191: have the proper protection modes.
192: Traditionally,
193: .UX
194: software has been exceedingly
195: permissive in this regard;
196: essentially all commands create files
197: readable and writable by everyone.
198: In the current version,
199: this policy may be easily adjusted to suit the needs of
200: the installation or the individual user.
201: Associated with each process and its descendants
202: is a mask, which is in effect
203: .I and\fR\|-ed
204: with the mode of every file and directory created by
205: that process.
206: In this way, users can arrange that, by default,
207: all their files are no more accessible than they wish.
208: The standard mask, set by
209: .I login,
210: allows all permissions to the user himself and to his group,
211: but disallows writing by others.
212: .PP
213: To maintain both data privacy and
214: data integrity,
215: it is necessary, and largely sufficient,
216: to make one's files inaccessible to others.
217: The lack of sufficiency could follow
218: from the existence of set-UID programs
219: created by the user
220: and the possibility of total
221: breach of system security
222: in one of the ways discussed below
223: (or one of the ways not discussed below).
224: For greater protection,
225: an encryption scheme is available.
226: Since the editor is able to create encrypted
227: documents, and the
228: .I crypt
229: command can be used to pipe such documents into
230: the other text-processing programs,
231: the length of time during which cleartext versions
232: need be available is strictly limited.
233: The encryption scheme used is not one of the strongest
234: known, but it is judged adequate, in the sense that
235: cryptanalysis
236: is likely to require considerably more effort than more direct
237: methods of reading the encrypted files.
238: For example, a user who stores data that he regards as truly secret
239: should be aware that he is implicitly trusting the system
240: administrator not to install a version of the crypt command
241: that stores every typed password in a file.
242: .PP
243: Needless to say, the system administrators
244: must be at least as careful as their most
245: demanding user to place the correct
246: protection mode on the files under their
247: control.
248: In particular,
249: it is necessary that special files be protected
250: from writing, and probably reading, by ordinary
251: users when
252: they store sensitive files belonging to other
253: users.
254: It is easy to write programs that examine and change
255: files by accessing the device
256: on which the files live.
257: .PP
258: On the issue of password security,
259: .UX
260: is probably better than most systems.
261: Passwords are stored in an encrypted form
262: which, in the absence of serious attention
263: from specialists in the field,
264: appears reasonably secure,
265: provided its limitations are understood.
266: In the current version, it is based on a slightly
267: defective version of the Federal DES;
268: it is purposely defective so that
269: easily-available hardware is useless for attempts at exhaustive
270: key-search.
271: Since both the encryption algorithm and the encrypted passwords
272: are available,
273: exhaustive enumeration of potential passwords
274: is still feasible up to a point.
275: We have observed that users choose passwords that are easy to guess:
276: they are short, or from a limited alphabet, or
277: in a dictionary.
278: Passwords should be
279: at least six characters long and randomly chosen from an alphabet
280: which includes digits and special characters.
281: .PP
282: Of course there also exist
283: feasible non-cryptanalytic
284: ways of finding out passwords.
285: For example: write a program which types out ``login:\|''
286: on the typewriter and copies whatever is typed
287: to a file of your own.
288: Then invoke the command and go away until the victim arrives.
289: .PP
290: The set-UID (set-GID)
291: notion must be used carefully if any security is to be maintained.
292: The first thing to keep in mind is that
293: a writable set-UID file can have another program copied onto it.
294: For example, if the super-user
295: .I (su)
296: command is writable,
297: anyone can copy the shell
298: onto it and get a password-free version
299: of
300: .I su.
301: A more subtle problem
302: can come from
303: set-UID programs which are not sufficiently
304: careful of what is fed into them.
305: To take an obsolete example,
306: the previous version of the
307: .I mail
308: command was set-UID and owned by the super-user.
309: This version sent mail to the recipient's own directory.
310: The notion was that one should be able to send
311: mail to anyone even if they want to protect
312: their directories from writing.
313: The trouble was that
314: .I mail
315: was rather dumb:
316: anyone could mail someone else's private file to himself.
317: Much more serious
318: is the following scenario:
319: make a file with a line like one in the password file
320: which allows one to log in as the super-user.
321: Then make a link named ``.mail'' to the password file
322: in some writable
323: directory on the same device as the password file (say /tmp).
324: Finally mail the bogus login line to /tmp/.mail;
325: You can then login as the super-user,
326: clean up the incriminating evidence,
327: and have your will.
328: .PP
329: The fact that users can mount their own disks and tapes
330: as file systems
331: can be another way of gaining super-user status.
332: Once a disk pack is mounted, the system believes
333: what is on it.
334: Thus one can take a blank disk pack,
335: put on it anything desired,
336: and mount it.
337: There are obvious and unfortunate consequences.
338: For example:
339: a mounted disk with garbage on it will crash the
340: system;
341: one of the files on the mounted disk can easily be
342: a password-free version of
343: .I su;
344: other files can be unprotected entries for special files.
345: The only easy fix for this problem is to
346: forbid the use of
347: .I mount
348: to unprivileged users.
349: A partial solution, not so restrictive,
350: would be to have the
351: .I mount
352: command examine the special file for bad data,
353: set-UID programs owned by others, and accessible
354: special files,
355: and balk at unprivileged invokers.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.