Return to security.ms CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 17.security

Annotation of 43BSDReno/share/doc/smm/17.security/security.ms, revision 1.1

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

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.