
 ***************************************************************
 **                                                           **
 **   A Paper on "The Security of UNIX" by Dennis M. Ritchie. **
 **       Aquired by Weapons, Distriubted by THUGS.           **
 **             A Solsbury Hill Text File.                    **
 **                                                           **
 ***************************************************************

On the Security of UNIX Dennis M. Ritchie Recently there has been
much  interest  in  the security aspects of operating systems and
software.  At issue is the ability to prevent  undesired  disclo-
sure  of information, destruction of information, and harm to the
functioning of the system.  This paper discusses  the  degree  of
security  which  can  be  provided  under the system and offers a
number of hints on how to improve security.  The  first  fact  to
face  is  that  was not developed with security, in any realistic
sense, in mind; this fact  alone  guarantees  a  vast  number  of
holes.   (Actually the same statement can be made with respect to
most systems.) The area of security  in  which  is  theoretically
weakest  is  in protecting against crashing or at least crippling
the operation of the system.  The problem here is not  mainly  in
uncritical  acceptance  of  bad parameters to system calls- there
may be bugs in this area, but none are known- but rather in  lack
of  checks for excessive consumption of resources.  Most notably,
there is no limit on the amount of disk storage used,  either  in
total  space  allocated or in the number of files or directories.
Here is a particularly ghastly shell sequence guaranteed to  stop
the system: while : ; do         mkdir x         cd x done Either
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 any-
one 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, so unless users are in collusion  it
is  unlikely that any one can stop the system altogether.  Howev-
er, 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  programs as 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 is that it is generally
fairly easy to detect what has happened when disaster strikes, 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 generous  supply  of  resources  which  have  served  to
cushion  us  against  accidental overconsumption.  The picture is
considerably brighter in the area of  protection  of  information
from  unauthorized  perusal  and destruction.  Here the degree of
security seems (almost) adequate theoretically, and the  problems
lie  more in the necessity for care in the actual use of the sys-
tem.  Each file has associated with it eleven bits of  protection
information  together  with  a  user  identification number and a
user-group identification number (UID and GID).  Nine of the pro-
tection  bits  are  used  to  specify independently permission 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 pro-
cess generated by or for a user has associated with it an  effec-
tive  UID and a real UID, and an effective and real GID.  When an
attempt is made to access the file for reading, writing, or  exe-
cution,  the user process's effective UID is compared against the
file's UID; if a match is obtained, access  is  granted  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  to
match,  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 used only when the file is executed
as  a  program.   If, in this case, the set-UID bit is on for the
file, the effective UID for the process is changed to the UID as-
sociated  with  the  file;  the change persists until the process
terminates or until the UID changed again by another execution of
a set-UID file.  Similarly the effective group ID of a process is
changed to the GID associated with a file when that file is  exe-
cuted  and  has  the  set-GID bit set.  The real UID and GID of a
process do not change when any file is executed, but only as  the
result  of  a  privileged  system  call.  The basic notion 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 oth-
ers only by that program.  The classical  example  is  the  game-
playing  program  which  maintains  records  of the scores of its
players.  The program itself has to  read  and  write  the  score
file,  but  no  one  but the game's sponsor can be allowed unres-
tricted access to the file lest they manipulate the game to their
own 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 exe-
cuted 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  meaningless  operation,
the  execute-permission bit, for directories, is taken instead to
mean permission to search the directory for a given  file  during
the scanning of a path name; thus if a directory has execute per-
mission 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.   Write  permission  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 point
of view of security, much more serious special case is that there
is  a  ``super  user'' who is able to read any file and write any
non-directory.  The super-user is also able to change the protec-
tion  mode  and  the  owner UID and GID of any file and to invoke
privileged system calls.  It must be recognized that the mere no-
tion  of  a  super-user  is a theoretical, and usually practical,
blemish on any protection scheme.   The  first  necessity  for  a
secure  system  is  of course arranging that all files and direc-
tories have the proper protection modes.  Traditionally, software
has  been  exceedingly permissive in this regard; essentially all
commands create files readable and writable by everyone.  In  the
current  version,  this policy may be easily adjusted to suit the
needs of the installation or  the  individual  user.   Associated
with  each process and its descendants is a mask, which is in ef-
fect 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 by  others.   To  maintain  both
data  privacy  and  data  integrity, it is necessary, and largely
sufficient, to make one's files inaccessible to others.  The lack
of  sufficiency  could  follow from the existence of set-UID pro-
grams 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).  For greater protection, an encryption
scheme is available.  Since the editor is able to create encrypt-
ed documents, and the command can be used to pipe such  documents
into  the other text-processing programs, the length of time dur-
ing which cleartext versions need be available is strictly limit-
ed.   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 encrypted files.  For example, a user  who
stores  data that he regards as truly secret should be aware that
he is implicitly trusting the system administrator not to 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 in the field, appears reasonably secure, provided its
limitations  are understood.  In the current version, it is based
on a slightly defective version of the Federal DES;  it  is  pur-
posely defective so that easily-available hardware is useless for
attempts at exhaustive key-search.  Since both the encryption al-
gorithm  and  the  encrypted  passwords are available, exhaustive
enumeration of potential passwords is  still  feasible  up  to  a
point.   We  have  observed  that users choose passwords that are
easy to guess: they are short, or from a limited alphabet, or  in
a  dictionary.   Passwords should be at least six characters long
and randomly chosen from an alphabet which  includes  digits  and
special  characters.   Of  course  there also exist feasible non-
cryptanalytic ways of finding out passwords.  For example:  write
a program which types out ``login:'' on the typewriter and copies
whatever is typed to a file of your own.  Then invoke the command
and  go away until the victim arrives.  The set-UID (set-GID) no-
tion 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 have another program copied onto it.   For  example,  if  the
super-user command is writable, anyone can copy the shell onto it
and get a password-free version of A more subtle problem can come
from  set-UID programs which are not sufficiently careful of what
is fed into them.  To take an obsolete example, the previous ver-
sion  of  the  command  was  set-UID and owned by the super-user.
This version sent mail to the recipient's own directory.  The no-
tion  was  that one should be able to send mail to anyone even if
they want to protect their directories from writing.  The trouble
was  that  was  rather  dumb:  anyone  could  mail someone else's
private file to himself.  Much  more  serious  is  the  following
scenario:  make  a file with a line like one in the password file
which allows one to log in as the super-user.  Then make  a  link
named  ``.mail''  to the password file in some writable directory
on the same device as the password file (say /tmp).  Finally mail
the  bogus  login  line  to /tmp/.mail; You can then login as the
super-user, 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  super-user  status.
Once  a  disk pack is mounted, the system believes what is on it.
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 on  it  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 for-
bid the use of to unprivileged users.  A partial solution, not so
restrictive,  would  be  to  have the command examine the special
file for bad data, set-UID programs owned by others, and accessi-
ble special files, and balk at unprivileged invokers.

$

