| 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. |