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