home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / security < prev    next >
Encoding:
Text File  |  1979-01-10  |  11.7 KB  |  352 lines

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