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