Following is all the information that you need to understand the workings ofthe UNIX operating system (Berkley 4.2).Patched together by The WarOn the security side of UNIX:-----------------------------On the Security of UNIX Dennis M. Ritchie Recently there has been much interestin the security aspects of operating systems and software. At issue is theability to prevent undesired disclosure of information, destruction ofinformation, and harm to the functioning of the system. This paper discussesthe degree of security which can be provided under the system and offers anumber of hints on how to improve security. The first fact to face is that wasnot developed with security, in any realistic sense, in mind; this fact aloneguarantees a vast number of holes. (Actually the same statement can be madewith respect to most systems.) The area of security in which is theoreticallyweakest is in protecting against crashing or at least crippling the operationof the system.   The problem here is not mainly in uncritical acceptance of bad parametersto system calls there may be bugs in this area, but none are known- but ratherin lack of checks for excessive consumption of resources. Most notably, thereis no limit on the amount of disk storage used, either in total space allocatedor in the number of files or directories. Here is a particularly ghastly shellsequence guaranteed to stop the system:     while :; do         mkdir x         cd x      done Ether a panic will occur because all the i-nodes on the device are used up, or all the disk blocks will be consumed, thus preventing anyone from writing files on the device.  In this version  of the system, users are prevented from creating more than a set number of processes simultaneously, sounless users are in collusion it is unlikely that any one can stop the system altogether.  However, creation of 20 or so CPU or disk-bound jobs  leaves  few  resources available for others.  Also, if many large jobs are run simultaneously, swap space may run out, causing a panic.  It should be evident that excessive consumption of disk space, files, swap space, and  processes can  easily occur accidentally in malfunctioning programsas well as at command level.  In fact is  essentially defenseless against this kind of abuse, nor is there any easy fix.  The best that can be said isthat it is generally fairly easy to detect what has happened when disasterstrikes, to identify the user responsible, and take appropriate  action.In practice, we  have found that difficulties in this area are rather rare,but we have not been faced with malicious users, and enjoy a fairly generoussupply of resources which have served to cushion us against accidentaloverconsumption. The picture is considerably brighter in the area of protectionof information from unauthorized perusal and destruction. Here the degree ofsecurity seems (almost) adequate theoretically, and the problems lie more inthe necessity for care in the actual use of the system. Each file hasassociated with it eleven bits of protection information togetherwith a user identification number and a usergroup identification number (UIDand GID).  Nine of the protection bits are used to specify independentlypermission to read, to write, and to execute the file to the user himself,to members of the user's group, and to all other users.  Each process generated by or for a user has associated with it an effective UID anda real UID, and an effective and real GID.  When an attempt is made to accessthe file for  reading, writing,  or  execution, the user process's effectiveUID is compared against the file's UID; if a match is  obtained, access isgranted provided the read, write, or execute bit respectively for the user himself is present.  If the UID for the file and  for the process fail tomatch, but the GID's do match, the group bits are used; if the GID's do not match, the bits  for other users are tested.  The last two bits of each file's protection information, called the set-UID and set-GID  bits, are usedonly when the file is executed as a program.  If, in this case, the set-UIDbit is on for the  file, the effective UID for the process is changed to the UID associated with the file; the change persists until the process terminates or until the UID changed again by another execution of a set-UIDfile.  Similarly the effective  group ID of a process is changed to the GID associated with a file when that file is executed and has the set-GID  bit set.  The real UID and GID of a process do not change when any file isexecuted, but only as the result of a privileged system call.  The basicnotion of the set-UID and set-GID bits is that one may write a program which  is executable by others and which maintains files accessible to others only by that program.  The classical example is the game-playing  program  which maintains records of the scores of its players.  The program itself hasto read and write the score file, but no one but the game's sponsor can be allowed unrestricted access to the file lest they manipulate the game to theirown advantage.  The solution is to turn on the set-UID bit of the game program.When, and only when, it is invoked by players of the game, it may update the score file but ordinary programs executed by others cannot access the score.  There are a number of special cases involved in determining access permissions.  Since executing a directory as a program is a meaninglessoperation, the execute-permission bit, for directories, is taken instead to mean permission to  earch  he directory for a given file during the scanning ofa path name; thus if a directory  has execute  permission but no read permission for a given user, he may access files with known names in the  directory, but may not read (list) the entire contents of the directory. Writepermission on a directory is interpreted to mean  that the user may create and delete files in that directory; it is impossible for any user to write directly into any directory.  Another, and from the pointof view of security, much more serious special case is that there is a ``superuser'' who is able  to read any file and write any nondirectory.  Thesuper-user is also able to change the protection mode and  the owner UID and GID of any file and to invoke privileged system calls.  It must be recognized that the mere notion of a super-user is a theoretical, and usually practical, blemish on any protection scheme.  The first necessityfor a secure system is of course arranging that all files and directories have the proper protection modes. Traditionally, software has beenexceedingly permissive in this regard; essentially all commands create files  readable and writable by everyone. In the current version, this policy may beeasily adjusted to suit the needs of the  installation or the individual user.  Associated with each process and its descendants is a mask, which is ineffect with the mode of every file and directory created by that process. In this way, users can arrange that, by default, all their files are no more accessible than they wish.  The standard mask, set by allows all permissions to the user himself  and to his group, but disallows writing byothers.  To maintain both data privacy and data integrity, it is necessary, and largely sufficient, to make one's files inaccessible to others.  The lackof sufficiency could follow from the existence of set-UID programs created by the user and the possibility of total breach of system security in one of the ways discussed below  (or one of the ways not discussed below).  Forgreater protection, an encryption scheme is available.  Since the editor is able to create encrypted documents, and the command can be used to pipesuch documents into the other text-processing programs, the length of timeduring which cleartext versions need  be  available is strictly limited. The encryption scheme used is not one of the strongest known, but it is judged adequate, in the sense that  cryptanalysis is likely to require considerably more effort than more direct methods of reading the encryptedfiles.  For example, a user who stores data that he regards as truly secretshould be aware that he is implicitly trusting the system administrator notto install a version of the crypt command that stores every typed password in a  file.  Needless to say, the system administrators must be at least as careful as their most demanding user to place the correct protection mode on the files under their control.  In particular, it is necessary that  special files be protected from  writing, and probably reading, by ordinary users when they store sensitive files belonging to other users.  It is easy to write programs that examine and change files by accessing the device on which the files live.  On the issue of  password security, is probably better than most systems.  Passwords are stored in an encrypted form which, in the absence of serious attention from specialists inthe field, appears reasonably secure,  provided its  limitations areunderstood.  In the current version, it  is based on a slightly defectiveversion of the Federal DES;  it  is  purposely defective so that easily-available hardware is useless for attempts at exhaustive key-search.Since both the encryption algorithm and the encrypted passwords are available,exhaustive enumeration of potential passwords is still feasible  up to apoint.  We have observed that users choose passwords that are easy toguess: they are short, or from a limited alphabet, or in a dictionary.Passwords should be at least six characters long and randomly  chosenfrom an alphabet which includes digits and special characters.  Of coursethere also exist feasible non-cryptanalytic ways of finding outpasswords.  For example: write a program which types out ``login:'' onthe typewriter and  copies  whatever is  typed to a file of your own.  Theninvoke the command and go away until the victim  arrives.   The  set-UID  (set-GID) notion must be used carefully if any security is to be maintained.The first thing to keep in mind is that a  writable set-UID file can haveanother program copied onto it.  For example, if the super-user command iswritable,  anyone can copy the shell onto it and get a password-free versionof A more subtle problem can come from set-UID programs which are notsufficiently careful of what is fed into them.  To take an obsoleteexample, the previous version of the command was set-UID and owned by thesuper-user.  This version sent mail to the recipient's own directory.  Thenotion was that one should be able to send mail to anyone even if they wantto protect their directories from writing.  The trouble  was that wasrather dumb: anyone could  mail someone  else's private file to himself.  Muchmore serious is the following scenario:  make  a file with a line like one inthe password file which allows one to log in as the  super-user.  Then make alink  named  ``.mail'' to the password file in some writable directory on thesame device as the password  file (say/tmp).  Finally mail the bogus loginline to /tmp/.mail; You can then login as the superuser, clean up the incriminating evidence, and have your will.  The fact that users can mount their own disks and tapes as file systems can be another way of gaining superuser status.  Once a disk pack is mounted, the system believes what is onit. Thus one can take a  blank disk pack, put on it anything desired, and mount it.  There are obvious and  unfortunate consequences.   For example: a mounted disk with garbage onit will crash the system; one of the files  on  the  mounted disk can easily  be a password-free version of other files can be unprotected entries for special files.  The only easy fix for this problem is to forbid the use of to unprivileged users.  A partialsolution, not so restrictive, would be  to have  the  command examine thespecial file for bad data, set-UID  programs owned by others, andaccessible special files, and balk at  unprivileged invokers.-Info about the /etc/passwd file:---NME     passwd - password fileDSCRIPTION     Passwd contains for each user the following information:    name (login name, contains no upper case)     encrypted password     numerical user ID     numerical group ID     user's real name, office, extension, home phone.     initial working directory     program to use as Shell    The name may contain `&', meaning insert the login name.     This information is set by the chfn(1) command and used by     the finger(1) command.    This is an ASCII file.  Each field within each user's entry     is separated from the next by a colon.  Each user is     separated from the next by a new line.  If the password     field is null, no password is demanded; if the Shell field     is null, then /bin/sh is used.    This file resides in directory / etc.  Because of the     encrypted passwords, it can and does have general read     permission and can be used, for example, to map numerical user     ID's to names.    Appropriate precautions must be taken to lock the file     against changes if it is to be edited with a text editor;     vipw(8) does the necessary locking.FLES     /etc/passwdSE ALSO     getpwent(3), login(1), crypt(3), passwd(1), group(5),     chfn(1), finger(1), vipw(8), adduser(8)BGS     A binary indexed file format should be available for fast access.    User information (name, office, etc.) should be stored elsewhere.---   Now if you have had the patience to read all of this and you have digestedit you know everything that you need to know about the Unix system to hold upyour end of an intelligent conversation.Have fun!