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